From amenkov at openjdk.org Thu Feb 1 00:20:04 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Feb 2024 00:20:04 GMT Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 04:34:52 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line 65: >> >>> 63: for (String line : lines) { >>> 64: if (line.contains(key)) { >>> 65: String[] words = line.split(key + "|[, ]"); >> >> String.split() expect regexp as an argument >> Not sure how this code works (without escaping '$' and parentheses). >> I think it would be clearer to use standard regexp pattern/matcher, something like >> >> >> Pattern pattern = Pattern.compile("\\s+- <0x([0-9a-fA-F]+)>, \(a java/util/concurrent/locks/ReentrantLock\$NonfairSync\)"); >> for (String line: lines) { >> Matcher matcher = pattern.matcher(line); >> if (matcher.find()) { >> addressString = matcher.group(1); >> break; >> } >> } > > I think `key` doesn't really matter when doing the split. `key` is mainly for finding the right line. The split is for tokenizing that line into words, and the only parts that matters for that are ' ' and the ',' being used as word delimiters. I think `key` should just be removed from the regex. I think the source of the bug is code copied from ClhsdbInspect.java: > > // Escape the token "Method*=" because the split method uses > // a regex, not just a straight String. > String escapedKey = key.replace("*","\*"); > String[] words = line.split(escapedKey+"|[ ]"); > > In this case key is `Method*=`. The code works and the escaping and searching for `key` is necessary because we are looking for something like `Method*=<0x00000000ffc2ed70>`, but I think this could have been simplified by including `=` in the split pattern rather than all of `escapedKey`. Well, I see now. In this case `"[, ]"` separator should work fine. I still think that use of Matcher is much clear - regexp defines what you are looking for and extract the value you need. Also there is no need to split `jstackOutput` into lines - the whole jstack output can be passed to `Pattern.matcher`. But I don't force you if you prefer to extract the address manually. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17479#discussion_r1473643552 From cjplummer at openjdk.org Thu Feb 1 00:40:04 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Feb 2024 00:40:04 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024 23:05:19 GMT, Alex Menkov wrote: > The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 93: > 91: > 92: /* > 93: Per jvmtiHeapReferenceInfoField spec: I think you should also include mention that this is for JVMTI_HEAP_REFERENCE_STATIC_FIELD. Indentation should be fixed to match our C++ comment style, and the "bullets" from the spec should be included to make it clearer that these are two lists of steps. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 108: > 106: where n is the count of the fields in all the superinterfaces of I. > 107: > 108: 'Klass' struct contains all required data to calculate field indeces. "indices" test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 153: > 151: > 152: /* > 153: For each test object 'Object' struct is created and pointer to it set as a tag for jobject. Suggestion: For each test object, the 'Object' struct is created and a pointer to it is set as the jobject's tag. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 225: > 223: > 224: // Explores all interfaces implemented by 'klass' sorting out duplicates > 225: // and store them in the 'arr' starting from 'index'. Suggestion: // Explores all interfaces implemented by 'klass', sorts out duplicates, // and stores the interfaces in the 'arr' starting from 'index'. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 254: > 252: > 253: // And explore its superinterfaces. > 254: count += fill_interfaces(arr, index + count, env, interfaces[i]); I assume here we are always dealing with test classes that are known not to be deeply nested. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 348: > 346: > 347: jclass obj_klass = env->GetObjectClass(obj); > 348: Unnecessary newline. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 350: > 348: > 349: Klass* klass = Klass::explore(env, obj_klass); > 350: Unnecessary newline. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 492: > 490: Java_FieldIndicesTest_prepare(JNIEnv *env, jclass cls, jobject testObj) { > 491: Object::explore(env, testObj); > 492: fflush(0); stdout? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473643948 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473644156 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473646542 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473647766 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473649198 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473651074 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473651163 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473650827 From amenkov at openjdk.org Thu Feb 1 00:49:03 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Feb 2024 00:49:03 GMT Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v4] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 23:07:16 GMT, Chris Plummer wrote: >> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack: >> >> >> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117) >> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70) >> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36) >> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71) >> >> >> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type. >> >> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks). >> >> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument). >> >> The same changes are also being made to "clhsdb pstack". >> >> Tested with all tier1, tier2, and tier5 svc tests. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > simplify regex passed to String.split(). Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17479#pullrequestreview-1855155769 From amenkov at openjdk.org Thu Feb 1 01:38:21 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Feb 2024 01:38:21 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v2] In-Reply-To: References: Message-ID: <0EXmWapW93JzOUNKqm18DjTticdPsElGzyoMxAvFB6w=.b0aefd95-1780-4416-a0b2-af4c7cfdad7c@github.com> > The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17580/files - new: https://git.openjdk.org/jdk/pull/17580/files/6276448d..c5e7b787 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17580&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17580&range=00-01 Stats: 27 lines in 1 file changed: 1 ins; 3 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/17580.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17580/head:pull/17580 PR: https://git.openjdk.org/jdk/pull/17580 From amenkov at openjdk.org Thu Feb 1 01:52:04 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Feb 2024 01:52:04 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v2] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 00:17:57 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 93: > >> 91: >> 92: /* >> 93: Per jvmtiHeapReferenceInfoField spec: > > I think you should also include mention that this is for JVMTI_HEAP_REFERENCE_STATIC_FIELD. > > Indentation should be fixed to match our C++ comment style, and the "bullets" from the spec should be included to make it clearer that these are two lists of steps. Fixed. > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 108: > >> 106: where n is the count of the fields in all the superinterfaces of I. >> 107: >> 108: 'Klass' struct contains all required data to calculate field indeces. > > "indices" Fixed. > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 153: > >> 151: >> 152: /* >> 153: For each test object 'Object' struct is created and pointer to it set as a tag for jobject. > > Suggestion: > > For each test object, the 'Object' struct is created and a pointer to it is set as the jobject's tag. Fixed. Updated comment for 'Klass' class the same way > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 225: > >> 223: >> 224: // Explores all interfaces implemented by 'klass' sorting out duplicates >> 225: // and store them in the 'arr' starting from 'index'. > > Suggestion: > > // Explores all interfaces implemented by 'klass', sorts out duplicates, > // and stores the interfaces in the 'arr' starting from 'index'. Fixed. > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 254: > >> 252: >> 253: // And explore its superinterfaces. >> 254: count += fill_interfaces(arr, index + count, env, interfaces[i]); > > I assume here we are always dealing with test classes that are known not to be deeply nested. Yes, we explore only test classes/interfaces > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 348: > >> 346: >> 347: jclass obj_klass = env->GetObjectClass(obj); >> 348: > > Unnecessary newline. removed. > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 350: > >> 348: >> 349: Klass* klass = Klass::explore(env, obj_klass); >> 350: > > Unnecessary newline. removed > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 492: > >> 490: Java_FieldIndicesTest_prepare(JNIEnv *env, jclass cls, jobject testObj) { >> 491: Object::explore(env, testObj); >> 492: fflush(0); > > stdout? fflush(0) flashes all opened streams (including stout and stderr). It's to handle the case when some shared test routines log to stderr. But flash() expects `FILE *`, so I updated all calls to use `nullptr` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473693579 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473695968 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473696254 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473696356 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473698778 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473701344 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473701389 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1473701268 From cjplummer at openjdk.org Thu Feb 1 02:12:01 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Feb 2024 02:12:01 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v2] In-Reply-To: <0EXmWapW93JzOUNKqm18DjTticdPsElGzyoMxAvFB6w=.b0aefd95-1780-4416-a0b2-af4c7cfdad7c@github.com> References: <0EXmWapW93JzOUNKqm18DjTticdPsElGzyoMxAvFB6w=.b0aefd95-1780-4416-a0b2-af4c7cfdad7c@github.com> Message-ID: On Thu, 1 Feb 2024 01:38:21 GMT, Alex Menkov wrote: >> The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17580#pullrequestreview-1855244184 From mdoerr at openjdk.org Thu Feb 1 04:16:05 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 1 Feb 2024 04:16:05 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13] In-Reply-To: <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com> Message-ID: On Wed, 31 Jan 2024 15:06:54 GMT, Suchismith Roy wrote: >> src/hotspot/os/aix/os_aix.cpp line 1176: >> >>> 1174: strncpy(file_path,filename, buffer_length + 1); >>> 1175: char* const pointer_to_dot = strrchr(file_path, '.'); >>> 1176: assert(pointer_to_dot != nullptr, "Attempting to load a shared object without extension? %s", filename); >> >> This should not only be an assertion. I think the check could be used instead of the strcmp below. > > I didn't follow that. You mean i need to keep a check if it is null and print it out ? An assertion is only used for debug builds. Such an error should be handled in product builds as well. I think an attempt to load an invalid library should simply fail. You may add logging if needed. @tstuefe: Do you agree or have another proposal to handle such errors? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1473772905 From mdoerr at openjdk.org Thu Feb 1 04:20:05 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 1 Feb 2024 04:20:05 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com> Message-ID: On Thu, 1 Feb 2024 04:13:52 GMT, Martin Doerr wrote: >> I didn't follow that. You mean i need to keep a check if it is null and print it out ? > > An assertion is only used for debug builds. Such an error should be handled in product builds as well. I think an attempt to load an invalid library should simply fail. You may add logging if needed. > @tstuefe: Do you agree or have another proposal to handle such errors? In addition, the nullptr check is important to avoid undefined behavior when passing `pointer_to_dot` to any string function. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1473774551 From dholmes at openjdk.org Thu Feb 1 05:10:03 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Feb 2024 05:10:03 GMT Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump [v3] In-Reply-To: <4AmewOHYpmDuaD4H4sk9wb2z6EsQwJinORtc73FCIX0=.ea07369a-c8b0-4c99-8fe0-32ad8ffb9300@github.com> References: <4AmewOHYpmDuaD4H4sk9wb2z6EsQwJinORtc73FCIX0=.ea07369a-c8b0-4c99-8fe0-32ad8ffb9300@github.com> Message-ID: On Wed, 31 Jan 2024 06:41:44 GMT, Taizo Kurashige wrote: >> Changes requested by dholmes (Reviewer). > > @dholmes-ora @egahlin > > I'm sorry that my slow response has prolonged this issue. I created a subtask and modified the source. If possible, please review them. Thanks @kurashige23 , the manpage subtask will be handled by someone from Oracle. I'll leave it to JFR folk to do the review here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16413#issuecomment-1920524186 From dholmes at openjdk.org Thu Feb 1 05:25:05 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Feb 2024 05:25:05 GMT Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into java while holding a lock In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 18:57:23 GMT, Coleen Phillimore wrote: > This change uses a claim token to allocate multi dimensional arrays rather than holding MultiArray_lock around metaspace allocation. We can't hold a mutex around metaspace allocation because it can create an OOM object and it can also call into JVMTI for a resource exhausted event. Also, we were creating mirrors and more metadata arrays while holding this lock. See the bug for more details and other ideas considered and rejected. > > Tested with tier1-7. Can't you just use a Monitor to implement the claim token, rather than this lock-free approach? (Similar to how class initialization is handled.) ------------- PR Review: https://git.openjdk.org/jdk/pull/17660#pullrequestreview-1855472920 From dholmes at openjdk.org Thu Feb 1 05:46:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Feb 2024 05:46:06 GMT Subject: RFR: 8324668: JDWP process management needs more efficient file descriptor handling [v7] In-Reply-To: References: Message-ID: <_H7kSaBAJCTl0ryaWfi8M1BI1izlYoMsvkbxnZBtupY=.f94ed876-8f2c-489b-adf7-76d29a7a39bb@github.com> On Wed, 31 Jan 2024 08:01:15 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668? >> >> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Minor - fix alignment Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1855525479 From dholmes at openjdk.org Thu Feb 1 05:46:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Feb 2024 05:46:06 GMT Subject: RFR: 8324668: JDWP process management needs more efficient file descriptor handling [v6] In-Reply-To: References: <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com> Message-ID: <32nrZ25CGO0zFirzaOCiUv7IxklvVI_mO1miErtXcuU=.5a8dca1f-8480-408d-a117-ee18c4b06bb0@github.com> On Wed, 31 Jan 2024 07:52:18 GMT, Jaikiran Pai wrote: >> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 35: >> >>> 33: #include "sys.h" >>> 34: #include "util.h" >>> 35: #include "error_messages.h" >> >> Nit: to maintain include sort order this should have gone where `log_messages.h` was removed. > > Hello David, I had actually first put it in that line you noted, but that then lead to a compilation error: > > > In file included from /jdk/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c:33: > /jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:35:20: error: unknown type name 'FILE' > void print_message(FILE *fp, const char *prefix, const char *suffix, > ^ > /jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:41:29: error: a parameter list without types is only allowed in a function definition > const char * jvmtiErrorText(jvmtiError); > ^ > /jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:43:28: error: a parameter list without types is only allowed in a function definition > const char * jdwpErrorText(jdwpError); > ^ > 3 errors generated. > > > > I think the reason for those compilation errors is that `error_messages.h` and a few other header files are not explicitly listing their necessary includes and are relying on transitive includes. So I decided to take the easy route out, by adding the `error_messages.h` after the `util.h` to rely on the transitive includes to get past that compilation error. > > I think to properly fix that compile error, this following change (which I tested locally and works) would be needed: > > > diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h b/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h > index 92a9f457e8a..2683c6791a1 100644 > --- a/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h > +++ b/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h > @@ -26,6 +26,8 @@ > #ifndef JDWP_JDWP_H > #define JDWP_JDWP_H > > +#include "jni_md.h" > +#include "jvmti.h" > #include "JDWPCommands.h" > > /* > diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h b/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h > index 4126b76f226..810ab384f1a 100644 > --- a/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h > +++ b/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h > @@ -26,6 +26,9 @@ > #ifndef JDWP_ERROR_MESSAGES_H > #define JDWP_ERROR_MESSAGES_H > > +#include > +#include "JDWP.h" > + > /* It is assumed that ALL strings are UTF-8 safe on entry */ > #define TTY_MESSAGE(args) ( tty_message args ) > #define ERROR_MESSAGE(args) ( \ > diff --git a/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c b/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c > index b43d4de80fc..cf0d00db192 100644 > --- a/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c > +++ b/src/jdk.jdwp.agent... Please file a JBS issue, but no need for you to address it. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1473821677 From jpai at openjdk.org Thu Feb 1 06:01:11 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 1 Feb 2024 06:01:11 GMT Subject: Integrated: 8324668: JDWP process management needs more efficient file descriptor handling In-Reply-To: References: Message-ID: <9ko0P600bjlyABTfr5-F-i5eWMQJB6Paj4Qcw5SzPPc=.1ce9b047-e57d-48c6-a0ba-5d1b328323de@github.com> On Fri, 26 Jan 2024 14:52:49 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668? > > This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change. This pull request has now been integrated. Changeset: a6632487 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/a6632487863db5ff3136cdcc76b7440c15ce6be9 Stats: 121 lines in 1 file changed: 106 ins; 12 del; 3 mod 8324668: JDWP process management needs more efficient file descriptor handling Reviewed-by: gziemski, dholmes, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/17588 From jpai at openjdk.org Thu Feb 1 06:49:09 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 1 Feb 2024 06:49:09 GMT Subject: RFR: 8324668: JDWP process management needs more efficient file descriptor handling [v6] In-Reply-To: <32nrZ25CGO0zFirzaOCiUv7IxklvVI_mO1miErtXcuU=.5a8dca1f-8480-408d-a117-ee18c4b06bb0@github.com> References: <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com> <32nrZ25CGO0zFirzaOCiUv7IxklvVI_mO1miErtXcuU=.5a8dca1f-8480-408d-a117-ee18c4b06bb0@github.com> Message-ID: On Thu, 1 Feb 2024 05:42:07 GMT, David Holmes wrote: >> Hello David, I had actually first put it in that line you noted, but that then lead to a compilation error: >> >> >> In file included from /jdk/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c:33: >> /jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:35:20: error: unknown type name 'FILE' >> void print_message(FILE *fp, const char *prefix, const char *suffix, >> ^ >> /jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:41:29: error: a parameter list without types is only allowed in a function definition >> const char * jvmtiErrorText(jvmtiError); >> ^ >> /jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:43:28: error: a parameter list without types is only allowed in a function definition >> const char * jdwpErrorText(jdwpError); >> ^ >> 3 errors generated. >> >> >> >> I think the reason for those compilation errors is that `error_messages.h` and a few other header files are not explicitly listing their necessary includes and are relying on transitive includes. So I decided to take the easy route out, by adding the `error_messages.h` after the `util.h` to rely on the transitive includes to get past that compilation error. >> >> I think to properly fix that compile error, this following change (which I tested locally and works) would be needed: >> >> >> diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h b/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h >> index 92a9f457e8a..2683c6791a1 100644 >> --- a/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h >> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h >> @@ -26,6 +26,8 @@ >> #ifndef JDWP_JDWP_H >> #define JDWP_JDWP_H >> >> +#include "jni_md.h" >> +#include "jvmti.h" >> #include "JDWPCommands.h" >> >> /* >> diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h b/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h >> index 4126b76f226..810ab384f1a 100644 >> --- a/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h >> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h >> @@ -26,6 +26,9 @@ >> #ifndef JDWP_ERROR_MESSAGES_H >> #define JDWP_ERROR_MESSAGES_H >> >> +#include >> +#include "JDWP.h" >> + >> /* It is assumed that ALL strings are UTF-8 safe on entry */ >> #define TTY_MESSAGE(args) ( tty_message args ) >> #define ERROR_MESSAGE(args) ( \ >> diff --git a/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c b/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c >> index b43d4de80... > > Please file a JBS issue, but no need for you to address it. Thanks. I've created https://bugs.openjdk.org/browse/JDK-8325094 to track this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1473868787 From alanb at openjdk.org Thu Feb 1 06:56:02 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 1 Feb 2024 06:56:02 GMT Subject: RFR: 8324845: management.properties text "interface name" is misleading [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 21:29:14 GMT, Kevin Walls wrote: >> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts. It should just say it needs to be a host name or address. >> >> This change only affects comment text in a properties file. >> >> (We don't currently mention this property in other docs, e.g. in the M&M guide.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > text update Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17615#pullrequestreview-1855667712 From dholmes at openjdk.org Thu Feb 1 07:15:01 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Feb 2024 07:15:01 GMT Subject: RFR: 8325055: Rename Injector.h [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 15:15:16 GMT, Kim Barrett wrote: >> Please review this trivial change that renames the file >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix name in README Seems fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17656#pullrequestreview-1855696820 From ihse at openjdk.org Thu Feb 1 09:13:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 09:13:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). > > > diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1920844523 From kevinw at openjdk.org Thu Feb 1 09:21:07 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 1 Feb 2024 09:21:07 GMT Subject: RFR: 8324845: management.properties text "interface name" is misleading [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 21:29:14 GMT, Kevin Walls wrote: >> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts. It should just say it needs to be a host name or address. >> >> This change only affects comment text in a properties file. >> >> (We don't currently mention this property in other docs, e.g. in the M&M guide.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > text update Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17615#issuecomment-1920859573 From kevinw at openjdk.org Thu Feb 1 09:21:08 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 1 Feb 2024 09:21:08 GMT Subject: Integrated: 8324845: management.properties text "interface name" is misleading In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 14:45:24 GMT, Kevin Walls wrote: > We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts. It should just say it needs to be a host name or address. > > This change only affects comment text in a properties file. > > (We don't currently mention this property in other docs, e.g. in the M&M guide.) This pull request has now been integrated. Changeset: d9331bfd Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/d9331bfd49461c08e165e8f202cbbf88cc0ecec1 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8324845: management.properties text "interface name" is misleading Reviewed-by: mchung, alanb ------------- PR: https://git.openjdk.org/jdk/pull/17615 From sroy at openjdk.org Thu Feb 1 09:45:05 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 1 Feb 2024 09:45:05 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com> Message-ID: <92pALpvWlzVEyfziqyJTxCjUH6hEKeKnPinn-8QBB88=.3512f869-674f-4e5a-a8f0-37c09545ef4a@github.com> On Thu, 1 Feb 2024 04:17:41 GMT, Martin Doerr wrote: >> An assertion is only used for debug builds. Such an error should be handled in product builds as well. I think an attempt to load an invalid library should simply fail. You may add logging if needed. >> @tstuefe: Do you agree or have another proposal to handle such errors? > > In addition, the nullptr check is important to avoid undefined behavior when passing `pointer_to_dot` to any string function. Ok. So then may be we can return a nullptr and do a log_info(os) with the correct error report ? @tstuefe @TheRealMDoerr ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1474128334 From stuefe at openjdk.org Thu Feb 1 10:34:05 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 1 Feb 2024 10:34:05 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: <8OXB2hSdtUljShW9BxphktBQGlsmjGATVODGUxeKlho=.7c7f3ee8-bdaf-4723-a8e7-f9829bf3ae41@github.com> On Wed, 31 Jan 2024 13:17:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > spelling I'm busy with FOSDEM this week and probably next. Will look at this end of next week or the week after. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1921004805 From ihse at openjdk.org Thu Feb 1 12:02:12 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 12:02:12 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order Message-ID: This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. ------------- Commit messages: - 8325109: Sort method modifiers in canonical order Changes: https://git.openjdk.org/jdk/pull/17670/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17670&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325109 Stats: 61 lines in 39 files changed: 0 ins; 0 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/17670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17670/head:pull/17670 PR: https://git.openjdk.org/jdk/pull/17670 From alanb at openjdk.org Thu Feb 1 12:16:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 1 Feb 2024 12:16:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into jdk-FOB64 > - Move #include out of debug_util.h > - Restore AIX dirent64 et al defines > - Rollback AIX changes since they are now tracked in JDK-8324834 > - Remove superfluous setting of FOB64 > - Replace all foo64() with foo() for large-file functions in the JDK > - 8324539: Do not use LFS64 symbols in JDK libs I skimmed through the changes and they look okay. Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921189429 From mdoerr at openjdk.org Thu Feb 1 13:17:06 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 1 Feb 2024 13:17:06 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13] In-Reply-To: <92pALpvWlzVEyfziqyJTxCjUH6hEKeKnPinn-8QBB88=.3512f869-674f-4e5a-a8f0-37c09545ef4a@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com> <92pALpvWlzVEyfziqyJTxCjUH6hEKeKnPinn-8QBB88=.3512f869-674f-4e5a-a8f0-37c09545ef4a@github.com> Message-ID: On Thu, 1 Feb 2024 09:42:00 GMT, Suchismith Roy wrote: >> In addition, the nullptr check is important to avoid undefined behavior when passing `pointer_to_dot` to any string function. > > Ok. So then may be we can return a nullptr and do a log_info(os) with the correct error report ? @tstuefe @TheRealMDoerr I'd probably use `log_info(library)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1474449287 From dfuchs at openjdk.org Thu Feb 1 13:43:00 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 1 Feb 2024 13:43:00 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: <8VqjbOBjkNCr7PmXABZ1xmQqvF0jidmGyIMNUdKQDww=.8ffdc2ac-023f-4b79-ac5a-9ef541af68a7@github.com> On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Changes to IPAdressUtil look fine. I eyeballed the rest and didn't spot any issue. ------------- PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856519410 From mbaesken at openjdk.org Thu Feb 1 13:50:15 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 1 Feb 2024 13:50:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). > > > diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 > @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. Unfortunately it did not help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921367368 From ihse at openjdk.org Thu Feb 1 14:21:37 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:21:37 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v5] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove all system includes from debug_util.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/d6c64bc4..6e9ec631 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=03-04 Stats: 10 lines in 4 files changed: 6 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Thu Feb 1 14:27:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:27:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v6] In-Reply-To: References: Message-ID: <_ZwLqLPG2IQY-9lP4XO3KlStPatpZGye-Blofj9qfQQ=.dbffd3e3-1f37-4403-92de-63740436cde2@github.com> > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into jdk-FOB64 - Remove all system includes from debug_util.h - Merge branch 'master' into jdk-FOB64 - Move #include out of debug_util.h - Restore AIX dirent64 et al defines - Rollback AIX changes since they are now tracked in JDK-8324834 - Remove superfluous setting of FOB64 - Replace all foo64() with foo() for large-file functions in the JDK - 8324539: Do not use LFS64 symbols in JDK libs ------------- Changes: https://git.openjdk.org/jdk/pull/17538/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=05 Stats: 233 lines in 23 files changed: 14 ins; 105 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Thu Feb 1 14:27:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:27:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <3c6OBIr0CfTFj2PGPn3n3rzLkNxiNavNj-sOx5dWqTw=.64b85b44-36f1-44de-b187-93c6c94ebc9d@github.com> On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). >> >> >> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. > > > Unfortunately it did not help. @MBaesken How annoying. :( I have now tried to remove *all* system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921455438 From aivanov at openjdk.org Thu Feb 1 14:44:02 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 1 Feb 2024 14:44:02 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Looks good to me. I looked through all the changes. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856683827 From mbaesken at openjdk.org Thu Feb 1 15:57:06 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 1 Feb 2024 15:57:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). >> >> >> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. > > > Unfortunately it did not help. > @MBaesken How annoying. :( I have now tried to remove _all_ system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? The AIX (fast)debug build still fails . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921645170 From ihse at openjdk.org Thu Feb 1 16:21:05 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 16:21:05 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <1wzw4p_VVMn-Qkb6utSVBVN4HDK9uwRnr3MGDsxi51A=.5028d021-ecd3-45af-a9a1-2033a897cf9b@github.com> On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman wrote: > Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code. To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921697168 From rriggs at openjdk.org Thu Feb 1 17:02:01 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 Feb 2024 17:02:01 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. lgtm; all look good ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857031136 From darcy at openjdk.org Thu Feb 1 17:24:01 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Feb 2024 17:24:01 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Looks fine; I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857088376 From dnsimon at openjdk.org Thu Feb 1 18:29:10 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 1 Feb 2024 18:29:10 GMT Subject: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range Message-ID: The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. ------------- Commit messages: - disable ThreadCpuTimeArray with xcomp Changes: https://git.openjdk.org/jdk/pull/17675/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17675&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325137 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17675/head:pull/17675 PR: https://git.openjdk.org/jdk/pull/17675 From amenkov at openjdk.org Thu Feb 1 18:59:02 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Feb 2024 18:59:02 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 23:24:22 GMT, Chris Plummer wrote: >> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). >> Heap walking API implementation is the last user of the klasses. >> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code. >> Additionally removed/updated includes of reflectionUtils.hpp. >> >> Testing: >> - tier1..4; >> - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions); >> - new test from #17580 (now the test runs several times faster). > > src/hotspot/share/prims/jvmtiTagMap.cpp line 453: > >> 451: InstanceKlass* super_klass = ik->java_super(); >> 452: if (super_klass != nullptr) { >> 453: start_index += add_instance_fields(super_klass, start_index); > > Does hotspot have any rules against potentially very deep recursion that can overflow the stack? I looked at hotspot code and don't see "implementation limits" for level of inheritance, so it looks like a valid concern. Need to reimplement this without recursion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1474976858 From kbarrett at openjdk.org Thu Feb 1 19:11:01 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 1 Feb 2024 19:11:01 GMT Subject: RFR: 8325055: Rename Injector.h [v2] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 07:12:08 GMT, David Holmes wrote: > Seems fine. Thanks Trivial? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17656#issuecomment-1922036034 From cjplummer at openjdk.org Thu Feb 1 19:27:07 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Feb 2024 19:27:07 GMT Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v4] In-Reply-To: References: Message-ID: <201Haiip1WB_KxrmVAi8VJ9A-zpBKqEyrsL5dzSwZcI=.62d34e0c-98f2-4f94-ba84-7368f9a79835@github.com> On Wed, 31 Jan 2024 23:07:16 GMT, Chris Plummer wrote: >> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack: >> >> >> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117) >> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70) >> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36) >> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71) >> >> >> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type. >> >> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks). >> >> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument). >> >> The same changes are also being made to "clhsdb pstack". >> >> Tested with all tier1, tier2, and tier5 svc tests. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > simplify regex passed to String.split(). Thanks for the reviews Kevin and Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17479#issuecomment-1922065831 From cjplummer at openjdk.org Thu Feb 1 19:27:08 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Feb 2024 19:27:08 GMT Subject: Integrated: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 02:17:56 GMT, Chris Plummer wrote: > I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack: > > > at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117) > at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70) > at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36) > at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71) > > > This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type. > > Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks). > > This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument). > > The same changes are also being made to "clhsdb pstack". > > Tested with all tier1, tier2, and tier5 svc tests. This pull request has now been integrated. Changeset: 192349ee Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/192349eee4b6d50f16d44969eb882875c67d651d Stats: 228 lines in 10 files changed: 204 ins; 1 del; 23 mod 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow Reviewed-by: kevinw, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/17479 From amenkov at openjdk.org Thu Feb 1 21:05:13 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Feb 2024 21:05:13 GMT Subject: RFR: 8325055: Rename Injector.h [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 15:15:16 GMT, Kim Barrett wrote: >> Please review this trivial change that renames the file >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix name in README Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17656#pullrequestreview-1857623975 From prappo at openjdk.org Thu Feb 1 23:07:08 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 1 Feb 2024 23:07:08 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Changes to jdk.javadoc look fine. ------------- Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857871131 From amenkov at openjdk.org Thu Feb 1 23:07:11 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Feb 2024 23:07:11 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v2] In-Reply-To: References: Message-ID: <-yVjuuKrSxMjLrnjK8eW36a17zXTu2AViPuge7-7De4=.9a5cae31-61bb-481f-9289-abf00b05fa8f@github.com> > FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). > Heap walking API implementation is the last user of the klasses. > The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code. > Additionally removed/updated includes of reflectionUtils.hpp. > > Testing: > - tier1..4; > - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions); > - new test from #17580 (now the test runs several times faster). Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: remove recursion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17661/files - new: https://git.openjdk.org/jdk/pull/17661/files/5edae77e..c064abdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17661&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17661&range=00-01 Stats: 43 lines in 1 file changed: 18 ins; 23 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17661/head:pull/17661 PR: https://git.openjdk.org/jdk/pull/17661 From sspitsyn at openjdk.org Fri Feb 2 00:50:16 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Feb 2024 00:50:16 GMT Subject: RFR: 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage Message-ID: The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. The function returns the following structure: typedef struct { jthread owner; jint entry_count; jint waiter_count; jthread* waiters; jint notify_waiter_count; jthread* notify_waiters; } jvmtiMonitorUsage; The following four fields are defined this way: waiter_count [jint] The number of threads waiting to own this monitor waiters [jthread*] The waiter_count waiting threads notify_waiter_count [jint] The number of threads waiting to be notified by this monitor notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. This update makes it right. The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: jvmti/GetObjectMonitorUsage/objmonusage001 jvmti/GetObjectMonitorUsage/objmonusage003 The following JVMTI JCK tests have to be fixed to adopt to correct behavior: vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository by a separate sub-task before integration of this update. Also, please see and review the related CSR: [8324677](https://bugs.openjdk.org/browse/JDK-8324677) Specification clarification needed for JVM TI GetObjectMonitorUsage Testing: - tested with mach5 tiers 1-6 ------------- Commit messages: - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage Changes: https://git.openjdk.org/jdk/pull/17680/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324677 Stats: 25 lines in 5 files changed: 10 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From dholmes at openjdk.org Fri Feb 2 02:26:01 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Feb 2024 02:26:01 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 00:44:00 GMT, Serguei Spitsyn wrote: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository by a separate sub-task before integration of this update. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 src/hotspot/share/prims/jvmtiEnvBase.cpp line 1553: > 1551: Handle th(current_thread, get_vthread_or_thread_oop(w)); > 1552: if (java_lang_Thread::get_thread_status(w->threadObj()) == > 1553: JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER) { I don't think this is possible. `BLOCKED_ON_MONITOR_ENTER` is only set after the target has been removed from the wait-set and added to the cxq queue - see `ObjectMonitor::INotify`. As per the comment just above: // If the thread was found on the ObjectWaiter list, then // it has not been notified. which means it can't be trying to acquire the monitor either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1475436352 From amenkov at openjdk.org Fri Feb 2 02:49:13 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 2 Feb 2024 02:49:13 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v3] In-Reply-To: References: Message-ID: > FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). > Heap walking API implementation is the last user of the klasses. > The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code. > Additionally removed/updated includes of reflectionUtils.hpp. > > Testing: > - tier1..4; > - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions); > - new test from #17580 (now the test runs several times faster). Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: jcheck ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17661/files - new: https://git.openjdk.org/jdk/pull/17661/files/c064abdf..d6ab43b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17661&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17661&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17661/head:pull/17661 PR: https://git.openjdk.org/jdk/pull/17661 From amenkov at openjdk.org Fri Feb 2 02:49:13 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 2 Feb 2024 02:49:13 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v3] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 18:56:37 GMT, Alex Menkov wrote: >> src/hotspot/share/prims/jvmtiTagMap.cpp line 453: >> >>> 451: InstanceKlass* super_klass = ik->java_super(); >>> 452: if (super_klass != nullptr) { >>> 453: start_index += add_instance_fields(super_klass, start_index); >> >> Does hotspot have any rules against potentially very deep recursion that can overflow the stack? > > I looked at hotspot code and don't see "implementation limits" for level of inheritance, so it looks like a valid concern. > Need to reimplement this without recursion. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1475451497 From cjplummer at openjdk.org Fri Feb 2 03:04:02 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Feb 2024 03:04:02 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v3] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 02:49:13 GMT, Alex Menkov wrote: >> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). >> Heap walking API implementation is the last user of the klasses. >> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code. >> Additionally removed/updated includes of reflectionUtils.hpp. >> >> Testing: >> - tier1..4; >> - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions); >> - new test from #17580 (now the test runs several times faster). > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > jcheck Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17661#pullrequestreview-1858174309 From dholmes at openjdk.org Fri Feb 2 03:04:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Feb 2024 03:04:02 GMT Subject: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon wrote: > The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. > > The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. > > It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. Excluding Xcomp mode seems the most practical/expedient solution. Please update the 2023 copyright year to 2024. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17675#pullrequestreview-1858173944 From ihse at openjdk.org Fri Feb 2 06:40:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 06:40:01 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy wrote: > I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code. @jddarcy Any idea how to do that? I tried searching for JSR-166 and java.util.concurrent, but all I could find was talk about a now-deleted mailing list concurrency-interest, and a link to a [CVS repo for JDK8](http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/jsr166/src/jdk8/java/util/). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1923018074 From sspitsyn at openjdk.org Fri Feb 2 06:51:02 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Feb 2024 06:51:02 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v2] In-Reply-To: <0EXmWapW93JzOUNKqm18DjTticdPsElGzyoMxAvFB6w=.b0aefd95-1780-4416-a0b2-af4c7cfdad7c@github.com> References: <0EXmWapW93JzOUNKqm18DjTticdPsElGzyoMxAvFB6w=.b0aefd95-1780-4416-a0b2-af4c7cfdad7c@github.com> Message-ID: <-Xfr36nGp1LS7QZkpuYeGlln-z4Q24uNVRfr23NimUg=.7c485caf-c2fa-42fd-9c25-fc8feb87012a@github.com> On Thu, 1 Feb 2024 01:38:21 GMT, Alex Menkov wrote: >> The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback Nice test, thank you for developing it! Looks good. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 512: > 510: JNIEXPORT jboolean JNICALL > 511: Java_FieldIndicesTest_testFailed(JNIEnv *env, jclass cls) { > 512: return test_failed ? JNI_TRUE : JNI_FALSE; The indent for native files has to be 2, not 4. Even though there are still some tests with wrong indents I'd suggest for new files to follow this rule. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17580#pullrequestreview-1858460187 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1475611992 From ihse at openjdk.org Fri Feb 2 06:55:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 06:55:19 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add kludge to BufferedRenderPipe.c for AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/eb92119e..3c404183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=05-06 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Fri Feb 2 06:55:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 06:55:19 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> References: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> Message-ID: On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken wrote: >>> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. >> >> >> Unfortunately it did not help. > >> @MBaesken How annoying. :( I have now tried to remove _all_ system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? > > The AIX (fast)debug build still fails . @MBaesken Ok, I officially give up. :-( I added your patch from https://github.com/openjdk/jdk/pull/17538#issuecomment-1918699480. I agree that it is not elegant, but at least it works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923062901 From duke at openjdk.org Fri Feb 2 07:01:05 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:01:05 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX First, huge thanks for doing this. I did have a very rough cut of this locally which I'd put to one side, and you and I have done essentially the same thing (but yours with more tact). That's a positive sign. > > Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. > > I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code. > > To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...) Yeah, let's not, I think. The only way of doing this is with libc shims and a huge mess. As long as we have tests which handle > 2GB files in general, and then also we can get someone to run this on a 32-bit system and tell us if the test suite passes as-is, then we're fine. Really, even if it builds on a 32-bit system with strict `-Werror=x` for pointer conversions and such, then we're OK. I'll leave comments inline for the rest. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923093781 From duke at openjdk.org Fri Feb 2 07:05:07 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:05:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX make/modules/jdk.hotspot.agent/Lib.gmk line 31: > 29: > 30: ifeq ($(call isTargetOs, linux), true) > 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 We have two choices to feel a bit more comfortable: 1) We unconditionally `static_assert` in a few places for large `off_t`, or 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94: > 92: return IOS_UNSUPPORTED_CASE; > 93: > 94: loff_t offset = (loff_t)position; Is this `loff_t` for the benefit of `copy_file_range`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475635336 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475636686 From duke at openjdk.org Fri Feb 2 07:10:07 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:10:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: > 363: #else > 364: // Make sure we link to the 64-bit version of the functions > 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475642841 From dnsimon at openjdk.org Fri Feb 2 07:38:24 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Fri, 2 Feb 2024 07:38:24 GMT Subject: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2] In-Reply-To: References: Message-ID: > The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. > > The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. > > It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: fix date in header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17675/files - new: https://git.openjdk.org/jdk/pull/17675/files/4ff2f7cd..a3bc2653 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17675&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17675&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17675/head:pull/17675 PR: https://git.openjdk.org/jdk/pull/17675 From sspitsyn at openjdk.org Fri Feb 2 08:09:06 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Feb 2024 08:09:06 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v3] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 02:49:13 GMT, Alex Menkov wrote: >> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). >> Heap walking API implementation is the last user of the klasses. >> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code. >> Additionally removed/updated includes of reflectionUtils.hpp. >> >> Testing: >> - tier1..4; >> - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions); >> - new test from #17580 (now the test runs several times faster). > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > jcheck Looks good. There is one minor comment though. src/hotspot/share/prims/jvmtiTagMap.cpp line 499: > 497: } > 498: // update total_field_number for superclass > 499: total_field_number = start_index; Nit: The local variable name `total_field_number` is a little bit confusing because it is instantly decreased here (see also the line 490). I'm not sure what name to suggest though. Maybe the comment at line 498 needs an update to say this number is decreased here. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17661#pullrequestreview-1858613748 PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1475699883 From sspitsyn at openjdk.org Fri Feb 2 10:23:01 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Feb 2024 10:23:01 GMT Subject: RFR: 8323680: SA PointerFinder code can do a better job of leveraging existing code to determine if an address is in the TLAB [v2] In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 21:20:04 GMT, Chris Plummer wrote: >> In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block. >> >> I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on. >> >> It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on: >> >> rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000 >> >> rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_java >> ) [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490}) >> >> For testing I ran all tier1, tier2, and tier5 svc tests (still in progress) > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of inTLAB field. Not needed The fix looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17494#pullrequestreview-1858878750 From sspitsyn at openjdk.org Fri Feb 2 10:26:01 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Feb 2024 10:26:01 GMT Subject: RFR: 8325055: Rename Injector.h [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 15:15:16 GMT, Kim Barrett wrote: >> Please review this trivial change that renames the file >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix name in README Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17656#pullrequestreview-1858886273 From sspitsyn at openjdk.org Fri Feb 2 10:30:01 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Feb 2024 10:30:01 GMT Subject: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote: >> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. >> >> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. >> >> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fix date in header Looks good. Thank you for fixing! ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17675#pullrequestreview-1858895296 From dnsimon at openjdk.org Fri Feb 2 10:47:05 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Fri, 2 Feb 2024 10:47:05 GMT Subject: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote: >> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. >> >> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. >> >> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fix date in header Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923543404 From dnsimon at openjdk.org Fri Feb 2 10:47:05 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Fri, 2 Feb 2024 10:47:05 GMT Subject: Integrated: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon wrote: > The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. > > The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. > > It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. This pull request has now been integrated. Changeset: 91d8dac9 Author: Doug Simon URL: https://git.openjdk.org/jdk/commit/91d8dac9cff5689abcf2fc8950b15d284f933afd Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/17675 From kevinw at openjdk.org Fri Feb 2 10:51:07 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 2 Feb 2024 10:51:07 GMT Subject: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote: >> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. >> >> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. >> >> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fix date in header It doesn't seem that critical to test this with -Xcomp But just checking: the threads are meant to be waiting, after we call waitUntilThreadBlocked(), so do they wake up and do some deopt or compilation work for some reason? Or maybe they are not done the initial -Xcomp compile and waitUntilThreadBlocked() is mistakenly thinking they are now idle... ------------- PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923550642 From dnsimon at openjdk.org Fri Feb 2 11:08:07 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Fri, 2 Feb 2024 11:08:07 GMT Subject: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 10:48:26 GMT, Kevin Walls wrote: > Or maybe they are not done the initial -Xcomp compile and waitUntilThreadBlocked() is mistakenly thinking they are now idle... Yes, I believe this is the case. It's not really clear to me what the test is testing. As far as I can see, if the 2 timings are meant to be taken when the worker threads are idle, I would have thought the expected delta should be 0. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923578655 From kevinw at openjdk.org Fri Feb 2 11:31:06 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 2 Feb 2024 11:31:06 GMT Subject: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2] In-Reply-To: References: Message-ID: <9Z7N57uRRLZArmFKsHzJ6sg-Jab9d4hyKVLAJCT7d04=.5b1df68d-d2a8-4982-a20a-ca48198ef150@github.com> On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote: >> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. >> >> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. >> >> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fix date in header Yes, if you're idle, you should not have used any cpu time, that's what I think it's testing, and the 100 ms slack (DELTA) to account for slack in the accounting. If compilation makes a thread state Thread.State.WAITING then it would fool the check in waitUntilThreadBlocked(). Next time it causes trouble that check could be revisited... 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923615761 From ihse at openjdk.org Fri Feb 2 15:53:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:53:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> On Fri, 2 Feb 2024 07:02:43 GMT, Sam James wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Add kludge to BufferedRenderPipe.c for AIX > > src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94: > >> 92: return IOS_UNSUPPORTED_CASE; >> 93: >> 94: loff_t offset = (loff_t)position; > > Is this `loff_t` for the benefit of `copy_file_range`? That is how copy_file_range is defined. The cast to off64_t was technically incorrect (but they ended up being the same type). > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: > >> 363: #else >> 364: // Make sure we link to the 64-bit version of the functions >> 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); > > Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) I wrote earlier: > There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476232283 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476229335 From ihse at openjdk.org Fri Feb 2 15:53:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:53:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> References: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> Message-ID: On Fri, 2 Feb 2024 15:48:04 GMT, Magnus Ihse Bursie wrote: >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: >> >>> 363: #else >>> 364: // Make sure we link to the 64-bit version of the functions >>> 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); >> >> Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) > > I wrote earlier: > >> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.) Basically, my understanding is that a call to "openat" in the source file will be converted into a call to openat64 on 32-bit platforms. When we look up the function using dlsym, I assume we need to find the 64-bit version directly. Even if this is incorrect, it seems at least *safe* to do it this way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476231574 From ihse at openjdk.org Fri Feb 2 15:57:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:57:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Add kludge to BufferedRenderPipe.c for AIX > > make/modules/jdk.hotspot.agent/Lib.gmk line 31: > >> 29: >> 30: ifeq ($(call isTargetOs, linux), true) >> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 > > We have two choices to feel a bit more comfortable: > 1) We unconditionally `static_assert` in a few places for large `off_t`, or > 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). > > Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. I'm guessing your comment was really more general, and just happened to be placed here? The reason I am removing `-D_FILE_OFFSET_BITS=64` here is that it is always set for all JDK compilations. 1. I don't know why you would not trust that compiler flags in the build system would work, but if you really want to add a static_assert, let me know where you want it. 2. No, AIX is not handled separately. It is handled as part of this PR. You are probably thinking about JDK-8324834, but that was only about Hotspot. This PR is about all the other JDK native libraries. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476236956 From kbarrett at openjdk.org Fri Feb 2 16:24:21 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Feb 2024 16:24:21 GMT Subject: RFR: 8325055: Rename Injector.h [v3] In-Reply-To: References: Message-ID: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp. > > Testing: mach5 tier1 Kim Barrett 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 Injector - fix name in README - rename Injector.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17656/files - new: https://git.openjdk.org/jdk/pull/17656/files/0ab5cf73..02077283 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17656&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17656&range=01-02 Stats: 6112 lines in 157 files changed: 4498 ins; 767 del; 847 mod Patch: https://git.openjdk.org/jdk/pull/17656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17656/head:pull/17656 PR: https://git.openjdk.org/jdk/pull/17656 From kbarrett at openjdk.org Fri Feb 2 16:24:21 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Feb 2024 16:24:21 GMT Subject: RFR: 8325055: Rename Injector.h [v3] In-Reply-To: References: Message-ID: <9T0-H_QuzJlcl9GHESAoDSipQ0uOdhU3c7kuRGT-xlk=.7ccc9bb1-1367-47f3-ba3f-ff6d78b47ff1@github.com> On Thu, 1 Feb 2024 07:12:08 GMT, David Holmes wrote: >> Kim Barrett 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 Injector >> - fix name in README >> - rename Injector.h > > Seems fine. > Thanks Thanks for reviews @dholmes-ora , @alexmenkov , and @sspitsyn . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17656#issuecomment-1924195846 From kbarrett at openjdk.org Fri Feb 2 16:24:22 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Feb 2024 16:24:22 GMT Subject: Integrated: 8325055: Rename Injector.h In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 15:08:14 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 6787c4c3 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/6787c4c3dd11d4d8db8255e59a1d71b6ab03cebb Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 mod 8325055: Rename Injector.h Reviewed-by: dholmes, amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/17656 From kbarrett at openjdk.org Fri Feb 2 16:38:30 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Feb 2024 16:38:30 GMT Subject: RFR: 8325180: Rename jvmti_FollowRefObjects.h Message-ID: Please review this trivial change that renames the file test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file. Testing: mach5 tier1 ------------- Commit messages: - rename NULLs in jvmti_FollwRefObjects.hpp - rename jvmti_FollowRefObjects.h Changes: https://git.openjdk.org/jdk/pull/17689/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17689&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325180 Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17689/head:pull/17689 PR: https://git.openjdk.org/jdk/pull/17689 From sspitsyn at openjdk.org Fri Feb 2 17:52:02 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Feb 2024 17:52:02 GMT Subject: RFR: 8325180: Rename jvmti_FollowRefObjects.h In-Reply-To: References: Message-ID: <6G5ULxx7CdvwKjmEIl0e3xwI6K-dYP3fWT0raVe6EV0=.35e20b87-1908-4ab6-9fb7-53d8a6e207f7@github.com> On Fri, 2 Feb 2024 16:34:19 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h > to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file. > > Testing: mach5 tier1 Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17689#pullrequestreview-1859989205 From kevinw at openjdk.org Fri Feb 2 18:35:16 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 2 Feb 2024 18:35:16 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information Message-ID: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". Not recommended for live production use. Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools. ------------- Commit messages: - Tidy up the safety checks - Whitebox not required, just check option properties. - unnecessary parameter to find - Test update. Recognise ZGC oops differently. Formatting. - typo - Separate is_good_oop... method to avoid changing existing asserts. - More oop safety - 8318026: jcmd should provide access to low-level JVM debug information Changes: https://git.openjdk.org/jdk/pull/17655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318026 Stats: 371 lines in 5 files changed: 369 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655 PR: https://git.openjdk.org/jdk/pull/17655 From kevinw at openjdk.org Fri Feb 2 18:35:16 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 2 Feb 2024 18:35:16 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote: > Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". > > Not recommended for live production use. Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools. (I started a CSR but have withdraw it, as it is established that jcmd is a diagnostic tool, and does not require a CSR for new options, similar to HotSpot diagnostic flags). Adding jcmd access to debug tools, for a live process. That includes a process started with -XX:+ShowMessageBoxOnError which has stopped with an error. At that point, the VM has not created the hs_err fatal error log, but we can already run "jcmd PID VM.info", to provide much of what would appear in the hs_err log, and a native debugger can be attached to discover the call stack. The "find" subcommand reads an address from the text of its parameter, to lookup pointers found in VM.info output or in gdb sessions. It is protected by the UnlockDiagnosticVMOptions option (so is always enabled in debug builds). With the dbg_is_good_oop changes here, I can examine hundreds of pointers around a known good oop, recognise bad objects as such and skip them, without crashing. Before the additions, it was possible to crash the target, e.g. following a null klass pointer when looking at an address that is not an object. The "not recommended for live production use" advice still stands, and diagnostic option requirements remain, in case a crash is possible when the find command is given a pointer to the right (or wrong) kind of data in the Java heap. Aimed at people with source code access/familiarity, hence not documenting the findclass/findmethod flags in great detail. Commands and output should be expected to evolve. Thanks @LudwikJaniuk for the nits above, and for the other testing you did with this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1921013935 PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1923692015 From lujaniuk at openjdk.org Fri Feb 2 18:35:16 2024 From: lujaniuk at openjdk.org (Ludvig Janiuk) Date: Fri, 2 Feb 2024 18:35:16 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote: > Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". > > Not recommended for live production use. Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools. test/hotspot/jtreg/serviceability/dcmd/vm/VMDebugTest.java line 178: > 176: String p = m.group(regexGroup); > 177: ptr = new BigInteger(p, 16); > 178: System.out.println("Found '" + pattern +"', using pointer: 0x" + ptr.toString(16)); Would it be more logical to say this? "Found pointer: 0x" + ptr.toString(16)'" + " for pattern " +pattern test/hotspot/jtreg/serviceability/dcmd/vm/VMDebugTest.java line 201: > 199: run(new JMXExecutor()); > 200: } > 201: */ comment to remove ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1474686608 PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1474688481 From lujaniuk at openjdk.org Fri Feb 2 18:35:16 2024 From: lujaniuk at openjdk.org (Ludvig Janiuk) Date: Fri, 2 Feb 2024 18:35:16 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: On Thu, 1 Feb 2024 15:47:24 GMT, Ludvig Janiuk wrote: >> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". >> >> Not recommended for live production use. Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools. > > test/hotspot/jtreg/serviceability/dcmd/vm/VMDebugTest.java line 201: > >> 199: run(new JMXExecutor()); >> 200: } >> 201: */ > > comment to remove plus some formatting below in this file ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1474688937 From cjplummer at openjdk.org Fri Feb 2 20:44:04 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Feb 2024 20:44:04 GMT Subject: RFR: 8323680: SA PointerFinder code can do a better job of leveraging existing code to determine if an address is in the TLAB [v2] In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 21:20:04 GMT, Chris Plummer wrote: >> In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block. >> >> I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on. >> >> It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on: >> >> rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000 >> >> rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_java >> ) [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490}) >> >> For testing I ran all tier1, tier2, and tier5 svc tests (still in progress) > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of inTLAB field. Not needed Thanks for the reviews Kevin and Seguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17494#issuecomment-1924667202 From cjplummer at openjdk.org Fri Feb 2 20:44:05 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Feb 2024 20:44:05 GMT Subject: Integrated: 8323680: SA PointerFinder code can do a better job of leveraging existing code to determine if an address is in the TLAB In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 22:54:26 GMT, Chris Plummer wrote: > In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block. > > I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on. > > It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on: > > rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000 > > rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_java > ) [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490}) > > For testing I ran all tier1, tier2, and tier5 svc tests (still in progress) This pull request has now been integrated. Changeset: 7476e290 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/7476e2905380a60c7653cb69e1afded116852785 Stats: 56 lines in 2 files changed: 25 ins; 22 del; 9 mod 8323680: SA PointerFinder code can do a better job of leveraging existing code to determine if an address is in the TLAB Reviewed-by: kevinw, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/17494 From thomas.stuefe at gmail.com Fri Feb 2 21:42:17 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 2 Feb 2024 22:42:17 +0100 Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: Hi Kevin, Having a clear command spec to read and argue about would be helpful, especially since this is not a simple commnd but a whole command group. Exposing such a low level interface (this is supposed to go into product VMs, right?) may carry some risks that could arguably fall unter CSR. That said, what use case do you envisage? To me, these commands are usually only useful in the debugger, when I deal with numerical adresses. Cheers, Thomas p.s. please note that many folks are at fosdem right now. On Fri 2. Feb 2024 at 19:35, Kevin Walls wrote: > Introduce the jcmd "VM.debug" to implement access to a useful set of the > established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". > > Not recommended for live production use. Calling these "debug" utilities, > and not including them in the jcmd help output, is to remind us they are > not general customer-facing tools. > > ------------- > > Commit messages: > - Tidy up the safety checks > - Whitebox not required, just check option properties. > - unnecessary parameter to find > - Test update. Recognise ZGC oops differently. Formatting. > - typo > - Separate is_good_oop... method to avoid changing existing asserts. > - More oop safety > - 8318026: jcmd should provide access to low-level JVM debug information > > Changes: https://git.openjdk.org/jdk/pull/17655/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8318026 > Stats: 371 lines in 5 files changed: 369 ins; 0 del; 2 mod > Patch: https://git.openjdk.org/jdk/pull/17655.diff > Fetch: git fetch https://git.openjdk.org/jdk.git > pull/17655/head:pull/17655 > > PR: https://git.openjdk.org/jdk/pull/17655 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amenkov at openjdk.org Fri Feb 2 23:10:32 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 2 Feb 2024 23:10:32 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v3] In-Reply-To: References: Message-ID: > The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: indent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17580/files - new: https://git.openjdk.org/jdk/pull/17580/files/c5e7b787..a0fffef3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17580&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17580&range=01-02 Stats: 391 lines in 1 file changed: 56 ins; 56 del; 279 mod Patch: https://git.openjdk.org/jdk/pull/17580.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17580/head:pull/17580 PR: https://git.openjdk.org/jdk/pull/17580 From amenkov at openjdk.org Fri Feb 2 23:23:01 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 2 Feb 2024 23:23:01 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v2] In-Reply-To: <-Xfr36nGp1LS7QZkpuYeGlln-z4Q24uNVRfr23NimUg=.7c485caf-c2fa-42fd-9c25-fc8feb87012a@github.com> References: <0EXmWapW93JzOUNKqm18DjTticdPsElGzyoMxAvFB6w=.b0aefd95-1780-4416-a0b2-af4c7cfdad7c@github.com> <-Xfr36nGp1LS7QZkpuYeGlln-z4Q24uNVRfr23NimUg=.7c485caf-c2fa-42fd-9c25-fc8feb87012a@github.com> Message-ID: <5Xd4TiF2iRFUwaAr8gLLvqnNnIPEph_jD65Lh8lYThs=.36fbdfcf-928c-4ccb-93f5-e2fe2e3c1a81@github.com> On Fri, 2 Feb 2024 06:47:22 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 512: > >> 510: JNIEXPORT jboolean JNICALL >> 511: Java_FieldIndicesTest_testFailed(JNIEnv *env, jclass cls) { >> 512: return test_failed ? JNI_TRUE : JNI_FALSE; > > The indent for native files has to be 2, not 4. Even though there are still some tests with wrong indents I'd suggest for new files to follow this rule. Fixed. Going to integrate the change after sanity testing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1476865492 From cjplummer at openjdk.org Fri Feb 2 23:28:09 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Feb 2024 23:28:09 GMT Subject: RFR: 8323681: SA PointerFinder code should support G1 Message-ID: This PR adds G1 support to PointerFinder/PointerLocation. Previously we only had SerialGC support. Previously for G1 addresses SA would only report that the address is "In unknown section of Java heap" with no other details. Now it provides details for G1 addresses. Here are some examples for clhsdb `threadcontext` output. `threadcontext` dumps the contents of the thread's registers, some of which are often in the java heap. In the output below the first line is without verbose output and the 2nd is with: rbp: 0x00000000a0004080: In G1 heap region rbp: 0x00000000a0004080: In G1 heap Region: 0x00000000a0000000,0x00000000a0018a30,0x00000000a1000000:Old I also added an improvement to how SA deals with addresses in the TLAB. It used to only report that the address is in a TLAB and provide details about the TLAB in verbose mode. Now if verbose mode is used, the heap region information is included after the TLAB information. Here again is an example without and with verbose output: rsi: 0x0000000166000000: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f11c8029250 rsi: 0x0000000166000000: In TLAB for thread ("main" #1 prio=5 tid=0x00007f11c8029250 nid=1503 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_java ) [0x0000000166000000,0x00000001662d0c90,0x00000001667ffdc0,{0x0000000166800000}) In G1 heap Region: 0x0000000166000000,0x0000000166800000,0x0000000167000000:Eden Note at the end it indicates the address is in the Eden space, which is probably always the case for G1 TLAB addresses. For SerialGC is shows something similar. rsi: 0x0000000088ff99e0: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f0544029110 rsi: 0x0000000088ff99e0: In TLAB for thread ("main" #1 prio=5 tid=0x00007f0544029110 nid=3098 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_java ) [0x0000000088ff99e0,0x000000008978c090,0x0000000089ae54b0,{0x0000000089ae56f0}) In heap new generation: eden [0x0000000080200000,0x0000000089ae56f0,0x00000000a2420000) space capacity = 572653568, 27.99656213789626 used from [0x00000000a6860000,0x00000000a6860030,0x00000000aaca0000) space capacity = 71565312, 6.707160027472528E-5 used to [0x00000000a2420000,0x00000000a2420000,0x00000000a6860000) space capacity = 71565312, 0.0 used Testing all svc test in tier1, tier2, and tier5. Currently in progress. ------------- Commit messages: - Add G1 support to PointerFinder and PointerLocation. Changes: https://git.openjdk.org/jdk/pull/17691/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17691&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323681 Stats: 70 lines in 4 files changed: 54 ins; 6 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17691/head:pull/17691 PR: https://git.openjdk.org/jdk/pull/17691 From amenkov at openjdk.org Sat Feb 3 00:14:15 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 3 Feb 2024 00:14:15 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v4] In-Reply-To: References: Message-ID: <7px5fMfSU7Yeb-vJqp-20PUkX3Dh9Tr1PjeLlUcbq1g=.55b3d029-1be7-49ce-9d41-44ff2113b9b1@github.com> > FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). > Heap walking API implementation is the last user of the klasses. > The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code. > Additionally removed/updated includes of reflectionUtils.hpp. > > Testing: > - tier1..4; > - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions); > - new test from #17580 (now the test runs several times faster). Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: updated comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17661/files - new: https://git.openjdk.org/jdk/pull/17661/files/d6ab43b4..1152e718 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17661&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17661&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17661/head:pull/17661 PR: https://git.openjdk.org/jdk/pull/17661 From amenkov at openjdk.org Sat Feb 3 00:14:15 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 3 Feb 2024 00:14:15 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v3] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 08:05:06 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> jcheck > > src/hotspot/share/prims/jvmtiTagMap.cpp line 499: > >> 497: } >> 498: // update total_field_number for superclass >> 499: total_field_number = start_index; > > Nit: The local variable name `total_field_number` is a little bit confusing because it is instantly decreased here (see also the line 490). I'm not sure what name to suggest though. Maybe the comment at line 498 needs an update to say this number is decreased here. done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1476887153 From sspitsyn at openjdk.org Sat Feb 3 00:40:03 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Feb 2024 00:40:03 GMT Subject: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v4] In-Reply-To: <7px5fMfSU7Yeb-vJqp-20PUkX3Dh9Tr1PjeLlUcbq1g=.55b3d029-1be7-49ce-9d41-44ff2113b9b1@github.com> References: <7px5fMfSU7Yeb-vJqp-20PUkX3Dh9Tr1PjeLlUcbq1g=.55b3d029-1be7-49ce-9d41-44ff2113b9b1@github.com> Message-ID: On Sat, 3 Feb 2024 00:14:15 GMT, Alex Menkov wrote: >> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). >> Heap walking API implementation is the last user of the klasses. >> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code. >> Additionally removed/updated includes of reflectionUtils.hpp. >> >> Testing: >> - tier1..4; >> - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions); >> - new test from #17580 (now the test runs several times faster). > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated comment Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17661#pullrequestreview-1860685491 From sspitsyn at openjdk.org Sat Feb 3 00:47:05 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Feb 2024 00:47:05 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v3] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:10:32 GMT, Alex Menkov wrote: >> The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > indent Marked as reviewed by sspitsyn (Reviewer). test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 64: > 62: static bool is_static_field(JNIEnv* env, jclass klass, jfieldID fid) { > 63: enum { > 64: ACC_STATIC = 0x0008, Nit: Indent is 1 instead of 2. ------------- PR Review: https://git.openjdk.org/jdk/pull/17580#pullrequestreview-1860688173 PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1476897942 From amenkov at openjdk.org Sat Feb 3 01:38:23 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 3 Feb 2024 01:38:23 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v4] In-Reply-To: References: Message-ID: > The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: indent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17580/files - new: https://git.openjdk.org/jdk/pull/17580/files/a0fffef3..42e79303 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17580&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17580&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17580.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17580/head:pull/17580 PR: https://git.openjdk.org/jdk/pull/17580 From amenkov at openjdk.org Sat Feb 3 01:50:01 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 3 Feb 2024 01:50:01 GMT Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v3] In-Reply-To: References: Message-ID: On Sat, 3 Feb 2024 00:44:42 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> indent > > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp line 64: > >> 62: static bool is_static_field(JNIEnv* env, jclass klass, jfieldID fid) { >> 63: enum { >> 64: ACC_STATIC = 0x0008, > > Nit: Indent is 1 instead of 2. fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1476916568 From cjplummer at openjdk.org Sat Feb 3 04:28:24 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 3 Feb 2024 04:28:24 GMT Subject: RFR: 8323681: SA PointerFinder code should support G1 [v2] In-Reply-To: References: Message-ID: > This PR adds G1 support to PointerFinder/PointerLocation. Previously we only had SerialGC support. Previously for G1 addresses SA would only report that the address is "In unknown section of Java heap" with no other details. Now it provides details for G1 addresses. Here are some examples for clhsdb `threadcontext` output. `threadcontext` dumps the contents of the thread's registers, some of which are often in the java heap. In the output below the first line is without verbose output and the 2nd is with: > > > rbp: 0x00000000a0004080: In G1 heap region > rbp: 0x00000000a0004080: In G1 heap Region: 0x00000000a0000000,0x00000000a0018a30,0x00000000a1000000:Old > > > I also added an improvement to how SA deals with addresses in the TLAB. It used to only report that the address is in a TLAB and provide details about the TLAB in verbose mode. Now if verbose mode is used, the heap region information is included after the TLAB information. Here again is an example without and with verbose output: > > > rsi: 0x0000000166000000: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f11c8029250 > rsi: 0x0000000166000000: In TLAB for thread ("main" #1 prio=5 tid=0x00007f11c8029250 nid=1503 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_java > ) [0x0000000166000000,0x00000001662d0c90,0x00000001667ffdc0,{0x0000000166800000}) > In G1 heap Region: 0x0000000166000000,0x0000000166800000,0x0000000167000000:Eden > > > Note at the end it indicates the address is in the Eden space, which is probably always the case for G1 TLAB addresses. For SerialGC is shows something similar. > > > rsi: 0x0000000088ff99e0: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f0544029110 > rsi: 0x0000000088ff99e0: In TLAB for thread ("main" #1 prio=5 tid=0x00007f0544029110 nid=3098 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_java > ) [0x0000000088ff99e0,0x000000008978c090,0x0000000089ae54b0,{0x0000000089ae56f0}) > In heap new generation: eden [0x0000000080200000,0x0000000089ae56f0,0x00000000a2420000) space capacity = 572653568, 27.99656213789626 used > from [0x00000000a6860000,0x00000000a6860030,0x00000000aaca0000) space capacity = 71565312, 6.707160027472528E-5 used > to [0x00000000a2420000,0x00000000a2420000,0x00000000a6860000) space capacity = 71565312, 0.0 used > > > Testing all svc test in tier1, tier2, and tier5. Currently in progress. Chris Plummer has updated the pull request incrementally with three additional commits since the last revision: - Minor cleanup of output - Don't assert if the address is in the G1 heap, but not in an region. Not all of the mapped part of the heap is in use by regions. - Fix isInRegion() to check the entire region, not just the in use part. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17691/files - new: https://git.openjdk.org/jdk/pull/17691/files/6da5b903..37b3f17b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17691&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17691&range=00-01 Stats: 8 lines in 3 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17691/head:pull/17691 PR: https://git.openjdk.org/jdk/pull/17691 From jwaters at openjdk.org Sun Feb 4 14:13:03 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 4 Feb 2024 14:13:03 GMT Subject: RFR: 8325180: Rename jvmti_FollowRefObjects.h In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 16:34:19 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h > to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file. > > Testing: mach5 tier1 Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17689#pullrequestreview-1861434363 From dholmes at openjdk.org Sun Feb 4 22:50:17 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 4 Feb 2024 22:50:17 GMT Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC Message-ID: This update drops the "ea" from the version string. We also propagate the following fixes from the markdown sources to the troff manpage file: JDK-8322478: Update java manpage for multi-file source-code launcher JDK-8302233: HSS/LMS: keytool and jarsigner changes JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files Thanks. ------------- Commit messages: - 8322066: Update troff pages in JDK 22 before RC Changes: https://git.openjdk.org/jdk22/pull/104/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322066 Stats: 160 lines in 28 files changed: 63 ins; 15 del; 82 mod Patch: https://git.openjdk.org/jdk22/pull/104.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/104/head:pull/104 PR: https://git.openjdk.org/jdk22/pull/104 From dholmes at openjdk.org Sun Feb 4 23:10:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 4 Feb 2024 23:10:02 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote: > not including them in the jcmd help output, is to remind us they are not general customer-facing tools. Then who are they for? and do they really belong in the `jcmd` tool, or is that just convenient? Without help information who will know what can be done with this tool? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1925959472 From alanb at openjdk.org Mon Feb 5 07:24:01 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 5 Feb 2024 07:24:01 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: <9yBmnl6L5vdCdCT7f65HmOfKq-IqC6B2yvcSwgJtbrA=.c6d6f28b-c1b3-4e04-9cdf-eb795781754b@github.com> On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote: > Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". > > Not recommended for live production use. Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools. This proposal effectively opens a new side channel for debugging with several commands ("events", "find", "findclass", ...). This will surely end up in troubleshooting recipes and other documentation. For now, the commands look benign but it may be tempting for people to show up with changes that extend this for other things. So I think this feature needs wider review and a CSR should be submitted for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1926365013 From mbaesken at openjdk.org Mon Feb 5 08:29:06 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 08:29:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <7R-vR6xRkCutTiGye-lVtYvEjWVKLFYDWFCaj-Drcbc=.963a2048-d87a-4f4e-b93e-79a62b432138@github.com> On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX I noticed that in the file src/java.base/share/native/libzip/zlib/zconf.h we seem to still use `off64_t` , is this okay (at most other locations it was replaced) https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libzip/zlib/zconf.h#L541 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926448109 From sroy at openjdk.org Mon Feb 5 08:52:21 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 5 Feb 2024 08:52:21 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Change logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/af761abb..f4c1788b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=12-13 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From mdoerr at openjdk.org Mon Feb 5 09:04:08 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 Feb 2024 09:04:08 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 5 Feb 2024 08:52:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Change logging The trailing whitespace errors must get fixed (integration blocker). src/hotspot/os/aix/os_aix.cpp line 1183: > 1181: // If the load fails,we try to reload by changing the extension to .a for .so files only. > 1182: if (result == nullptr) { > 1183: if (strcmp(pointer_to_dot, ".so") == 0) { We could possibly reach here with `pointer_to_dot` == nullptr. Invoking strcmp causes undefined behavior! ------------- Changes requested by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1862189297 PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1477856818 From kevin.walls at oracle.com Mon Feb 5 09:04:18 2024 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 5 Feb 2024 09:04:18 +0000 Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: Hi Thomas - Yes, it goes into all builds, and yes this is a new jcmd with sub-commands, you could call it a group. It's not a large group of commands, and the commands themselves are not exactly new (but no objection to a CSR). Getting these debug utilities into a jcmd is about making them more discoverable and accessible (discoverability with bounds, still aimed at a narrow set of technical users), and also more testable. This does not compete with or replace existing debuggers if that's anybody's chosen route. I envisage just adding to the toolkit we have available. Live or at the time of a fault (e.g. MessageBoxOnError) we can inspect JVM state using existing jcmds. Now we can also inspect arbitrary Java heap objects, and items in other VM locations. This may be in parallel with a debugger. You can't run these while the JVM is stopped in another debugger 8-) but you may well attach something temporarily and see references that the JVM itself is well-placed to decode. Where VM.info or Thread.print give you Java object references, "VM.debug find" lets you inspect them, and continue following references with additional invocations. > many folks are at fosdem right now. I hope they have a great time. 8-) Thanks Kevin From: Thomas St?fe Sent: 02 February 2024 21:42 To: Kevin Walls Cc: hotspot-runtime-dev at openjdk.org; serviceability-dev at openjdk.org Subject: Re: RFR: 8318026: jcmd should provide access to low-level JVM debug information Hi Kevin, Having a clear command spec to read and argue about would be helpful, especially since this is not a simple commnd but a whole command group. Exposing such a low level interface (this is supposed to go into product VMs, right?) may carry some risks that could arguably fall unter CSR. That said, what use case do you envisage? To me, these commands are usually only useful in the debugger, when I deal with numerical adresses. Cheers, Thomas p.s. please note that many folks are at fosdem right now. On Fri 2. Feb 2024 at 19:35, Kevin Walls > wrote: Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". Not recommended for live production use. Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools. ------------- Commit messages: - Tidy up the safety checks - Whitebox not required, just check option properties. - unnecessary parameter to find - Test update. Recognise ZGC oops differently. Formatting. - typo - Separate is_good_oop... method to avoid changing existing asserts. - More oop safety - 8318026: jcmd should provide access to low-level JVM debug information Changes: https://git.openjdk.org/jdk/pull/17655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318026 Stats: 371 lines in 5 files changed: 369 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655 PR: https://git.openjdk.org/jdk/pull/17655 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinw at openjdk.org Mon Feb 5 09:08:04 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 5 Feb 2024 09:08:04 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: <9yBmnl6L5vdCdCT7f65HmOfKq-IqC6B2yvcSwgJtbrA=.c6d6f28b-c1b3-4e04-9cdf-eb795781754b@github.com> References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> <9yBmnl6L5vdCdCT7f65HmOfKq-IqC6B2yvcSwgJtbrA=.c6d6f28b-c1b3-4e04-9cdf-eb795781754b@github.com> Message-ID: <5mH844e5-8MC8If6kFytZDeLrdb9SpSYei_wNy3v8r8=.8fb43b52-cbb5-4451-ac90-a180ed8d7628@github.com> On Mon, 5 Feb 2024 07:21:05 GMT, Alan Bateman wrote: > ...needs wider review and a CSR should be submitted for this. Sure no problem I will refresh the linked CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1926513588 From mdoerr at openjdk.org Mon Feb 5 09:16:06 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 Feb 2024 09:16:06 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v11] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Wed, 31 Jan 2024 11:22:27 GMT, Joachim Kern wrote: >> The load library gets the entire library name, after construction from dll_build_name. This is always a .so file name. When .so file name fails to load, we fallback to .a filename. >> Do i need to mention the filename as libfilename.so then ? > > Yes, I think this would make it clear. Please use space after comma. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1477871269 From ihse at openjdk.org Mon Feb 5 09:19:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 09:19:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX zlib is 3rd party source, I did not touch those. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926532998 From sroy at openjdk.org Mon Feb 5 09:26:08 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 5 Feb 2024 09:26:08 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 5 Feb 2024 09:01:06 GMT, Martin Doerr wrote: >> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: >> >> Change logging > > src/hotspot/os/aix/os_aix.cpp line 1183: > >> 1181: // If the load fails,we try to reload by changing the extension to .a for .so files only. >> 1182: if (result == nullptr) { >> 1183: if (strcmp(pointer_to_dot, ".so") == 0) { > > We could possibly reach here with `pointer_to_dot` == nullptr. Invoking strcmp causes undefined behavior! Yes. Do we exit when there is no extension in the file ..or we can just append an extension manually and let the program flow go through. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1477884033 From yyang at openjdk.org Mon Feb 5 09:28:01 2024 From: yyang at openjdk.org (Yi Yang) Date: Mon, 5 Feb 2024 09:28:01 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote: > Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". > > Not recommended for live production use. Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools. Could it be extend to something like jcmd VM.debug MyDebugCode.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1926547862 From kevinw at openjdk.org Mon Feb 5 09:34:02 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 5 Feb 2024 09:34:02 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: On Sun, 4 Feb 2024 23:07:27 GMT, David Holmes wrote: > > not including them in the jcmd help output, is to remind us they are not general customer-facing tools. > > Then who are they for? and do they really belong in the `jcmd` tool, or is that just convenient? > > Without help information who will know what can be done with this tool? I want to suggest that these commands are not for everybody. But people investigating bugs in detail, including JVM crashes, might find these appealing, and should find the jcmd interface convenient. (It is convenient for the user, and also convenient to implement.) Proposing not having them in the standard jcmd help: I don't think most users should be attaching debuggers to their production JVMs, and I don't think most users should be doing these debug operations via jcmd on the same JVM. But we have a variety of expert users who want certain information. But I do think we should find other ways of documenting this, which might include our existing Troubleshooting Guide, but might well be something else. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1926559303 From kevinw at openjdk.org Mon Feb 5 09:56:01 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 5 Feb 2024 09:56:01 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: On Mon, 5 Feb 2024 09:25:24 GMT, Yi Yang wrote: > jcmd VM.debug MyDebugCode.java Are you thinking to run some Java code in the target JVM? VM.debug as presented here is all about inspecting JVM state, mostly using existing mechanisms but which were not already exposed in jcmd. I think this could be extended in future if needed. But I think executing arbitrary Java code is quite different and raises more questions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1926598031 From sspitsyn at openjdk.org Mon Feb 5 10:22:01 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 5 Feb 2024 10:22:01 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 02:22:54 GMT, David Holmes wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository by a separate sub-task before integration of this update. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1553: > >> 1551: Handle th(current_thread, get_vthread_or_thread_oop(w)); >> 1552: if (java_lang_Thread::get_thread_status(w->threadObj()) == >> 1553: JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER) { > > I don't think this is possible. `BLOCKED_ON_MONITOR_ENTER` is only set after the target has been removed from the wait-set and added to the cxq queue - see `ObjectMonitor::INotify`. As per the comment just above: > > // If the thread was found on the ObjectWaiter list, then > // it has not been notified. > > which means it can't be trying to acquire the monitor either. Thank you for looking at it and the comment, David! Will check what is possible here. Do you have any suggestions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1477954550 From mbaesken at openjdk.org Mon Feb 5 12:10:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:10:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX Current commit compiles nicely on AIX. One issue we might still have statvfs/statvfs64 is not mentioned here in the table of functions/structs redefined on AIX https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files so would we fall back to statvfs from the *64 - variant ? The define _LARGE_FILES might not help in this case on AIX . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926848063 From jkern at openjdk.org Mon Feb 5 12:20:07 2024 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 5 Feb 2024 12:20:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote: > Current commit compiles nicely on AIX. One issue we might still have statvfs/statvfs64 is not mentioned here in the table of functions/structs redefined on AIX https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files so would we fall back to statvfs from the *64 - variant ? The define _LARGE_FILES might not help in this case on AIX . Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on AIX to 32-Bit. _LARGE_FILES really does not help in this case! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926865295 From mbaesken at openjdk.org Mon Feb 5 12:25:07 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:25:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote: > Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on AIX to 32-Bit. _LARGE_FILES really does not help in this case! Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64 variant needs to stay on AIX. Seems the other symbols are covered by _LARGE_FILES according to the table in the linked IBM AIX doc (table in https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files ) , is that correct (Joachim?) or did I miss something ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926874075 From ihse at openjdk.org Mon Feb 5 12:41:11 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 12:41:11 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef _ALLBSD_SOURCE`, which I presume is not defined on AIX. I recommend that I push this PR as-is first, and then you can do a follow-up fix to define statvfs to statvfs64 on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926903203 From mbaesken at openjdk.org Mon Feb 5 12:51:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:51:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <_bDxv8SN2pD8KNWdhQ4SsTJMkbNyA2m9ERs87kg_yIk=.d76dcb5f-8f11-4515-ab0c-ceff66c09ffa@github.com> On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote: > It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef _ALLBSD_SOURCE`, which I presume is not defined on AIX. > > I recommend that I push this PR as-is first, and then you can do a follow-up fix to define statvfs to statvfs64 on AIX. Java_sun_nio_fs_UnixNativeDispatcher_statvfs0 is changed from statvfs64 to statvfs, did I miss something ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926925394 From ihse at openjdk.org Mon Feb 5 13:58:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 13:58:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX RIght, my bad. I apologize, you are completely correct, I turned the defines around in my head. I will add a redefine for AIX that turns statvfs into statvfs64. Thanks for noticing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927065583 From ihse at openjdk.org Mon Feb 5 14:06:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 14:06:21 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v8] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Redefine statvfs as statvfs64 on AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/3c404183..2de377cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=06-07 Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Mon Feb 5 14:06:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 14:06:21 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX I hope finally the AIX part of this PR is done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927082091 From mbaesken at openjdk.org Mon Feb 5 14:18:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 14:18:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote: > I hope finally the AIX part of this PR is done. Thanks for the AIX related effort ; I put it again into our internal build/test queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669 From jwaters at openjdk.org Mon Feb 5 16:17:01 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 16:17:01 GMT Subject: RFR: 8325180: Rename jvmti_FollowRefObjects.h In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 16:34:19 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h > to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file. > > Testing: mach5 tier1 Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17689#pullrequestreview-1863209709 From ihse at openjdk.org Mon Feb 5 16:27:05 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 16:27:05 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Tue, 28 Mar 2023 17:36:33 GMT, Chris Plummer wrote: > What was the reason for not moving forward with this PR? Me going on medical leave most of 2023... :-/ I intend to get this done now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11490#issuecomment-1927376112 From sgehwolf at openjdk.org Mon Feb 5 16:33:04 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 5 Feb 2024 16:33:04 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl wrote: > 8307977: jcmd and jstack broken for target processes running with elevated capabilities This looks good to me, but would like for somebody from the serviceability group to look at this as well. @plummercj perhaps? > _Mailing list message from [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) on [serviceability-dev](mailto:serviceability-dev at mail.openjdk.org):_ > > Is that actually safe to allow low priveledged user context to attach and control to a higher prived? It can at least overwrite files, but probably also inject code? On the native level a ptrace(2) would probably not be allowed. Note that for the dynamic attach mechanism the file ownership of the files the JVM creates on both sides need to match. In this case it's user `A` with potentially elevated privileges (e.g. to bind to a port), and the attach happens from user `A` as well (without the same elevated privileges). So this doesn't make the security worse. It remains questionable if it's safe to be allowed to attach in that case, but it's been like that in older releases (JDK 8). ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17628#pullrequestreview-1863246100 PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1927383380 From ihse at openjdk.org Mon Feb 5 16:45:38 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 16:45:38 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code [v2] In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Delete trailing \u0020 as per plummercj's suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11490/files - new: https://git.openjdk.org/jdk/pull/11490/files/1b418216..60fda42b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11490&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11490&range=00-01 Stats: 28 lines in 16 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/11490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11490/head:pull/11490 PR: https://git.openjdk.org/jdk/pull/11490 From ihse at openjdk.org Mon Feb 5 16:57:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 16:57:01 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code [v3] In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into properties-eol-serviceability - Delete trailing \u0020 as per plummercj's suggestions - 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code ------------- Changes: https://git.openjdk.org/jdk/pull/11490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11490&range=02 Stats: 19 lines in 11 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/11490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11490/head:pull/11490 PR: https://git.openjdk.org/jdk/pull/11490 From ihse at openjdk.org Mon Feb 5 16:57:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 16:57:01 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code [v3] In-Reply-To: References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Mon, 5 Feb 2024 16:53:54 GMT, Magnus Ihse Bursie wrote: >> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. >> >> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). >> >> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) >> >> Doing so has a dual benefit: >> >> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended >> >> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. >> >> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into properties-eol-serviceability > - Delete trailing \u0020 as per plummercj's suggestions > - 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27: > 25: > 26: agent.err.error = ?? > 27: agent.err.exception = ????? ????? ??????. I decided to remove the period here... src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 38: > 36: > 37: agent.err.agentclass.notfound = ?? ???? ???? ?? ? ????. > 38: agent.err.agentclass.failed = ?? ???? ???? ??????. ... but keep it here, as it aligned with the surrounding error messages. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11490#discussion_r1478576012 PR Review Comment: https://git.openjdk.org/jdk/pull/11490#discussion_r1478576479 From ihse at openjdk.org Mon Feb 5 16:58:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 16:58:56 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Tue, 28 Mar 2023 17:36:33 GMT, Chris Plummer wrote: >> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. >> >> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). >> >> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) >> >> Doing so has a dual benefit: >> >> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended >> >> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. >> >> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. > > What was the reason for not moving forward with this PR? Several of the original problems has been resolved since this PR was opened, but some remain. I believe this is now ready for integration, but I'd like to get a re-review from @plummercj. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11490#issuecomment-1927469254 From larry.cable at oracle.com Mon Feb 5 17:59:18 2024 From: larry.cable at oracle.com (Laurence Cable) Date: Mon, 5 Feb 2024 09:59:18 -0800 Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: <805d7242-5c1d-420f-8287-8ed8d59b982d@oracle.com> On 2/5/24 1:56 AM, Kevin Walls wrote: > On Mon, 5 Feb 2024 09:25:24 GMT, Yi Yang wrote: > >> jcmd VM.debug MyDebugCode.java > Are you thinking to run some Java code in the target JVM? > > VM.debug as presented here is all about inspecting JVM state, mostly using existing mechanisms but which were not already exposed in jcmd. I think this could be extended in future if needed. But I think executing arbitrary Java code is quite different and raises more questions. not too mention this is what is already supported with the attach API loadAgent facility, and is being disabled by default for security reasons. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1926598031 From darcy at openjdk.org Mon Feb 5 23:56:08 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 5 Feb 2024 23:56:08 GMT Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC In-Reply-To: References: Message-ID: On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote: > This update drops the "ea" from the version string. > > We also propagate the following fixes from the markdown sources to the troff manpage file: > > JDK-8322478: Update java manpage for multi-file source-code launcher > JDK-8302233: HSS/LMS: keytool and jarsigner changes > JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files > > > Thanks. Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk22/pull/104#pullrequestreview-1863882694 From amenkov at openjdk.org Mon Feb 5 23:56:31 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 5 Feb 2024 23:56:31 GMT Subject: Integrated: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes In-Reply-To: References: Message-ID: <5iPNVwVca_8UBv4T0zlBRimSnqrtLHiUDZxlRGCq0eE=.b2bd7879-72cd-4a72-8f2c-f561a846caf8@github.com> On Thu, 25 Jan 2024 23:05:19 GMT, Alex Menkov wrote: > The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. This pull request has now been integrated. Changeset: f31957e6 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/f31957e6a1c463e5c7041bf4eee4a1b09048e929 Stats: 643 lines in 2 files changed: 643 ins; 0 del; 0 mod 8317636: Improve heap walking API tests to verify correctness of field indexes Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/17580 From amenkov at openjdk.org Mon Feb 5 23:57:22 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 5 Feb 2024 23:57:22 GMT Subject: Integrated: JDK-8318566: Heap walking functions should not use FilteredFieldStream In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 21:28:34 GMT, Alex Menkov wrote: > FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). > Heap walking API implementation is the last user of the klasses. > The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code. > Additionally removed/updated includes of reflectionUtils.hpp. > > Testing: > - tier1..4; > - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions); > - new test from #17580 (now the test runs several times faster). This pull request has now been integrated. Changeset: fd3042a0 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/fd3042a04b2d76180cb90f688e8b33156fdf3d18 Stats: 272 lines in 10 files changed: 27 ins; 221 del; 24 mod 8318566: Heap walking functions should not use FilteredFieldStream Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/17661 From ihse at openjdk.org Tue Feb 6 00:03:31 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 00:03:31 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code [v4] In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: <9ezdxqyo0C-oR0r8bleXRJKI55qduwl9z3Lj2si_lpw=.46ae3241-62b3-489e-9342-ab10810e20d0@github.com> > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Restore period ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11490/files - new: https://git.openjdk.org/jdk/pull/11490/files/0c91a370..5acd13a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11490&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11490&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11490/head:pull/11490 PR: https://git.openjdk.org/jdk/pull/11490 From cjplummer at openjdk.org Tue Feb 6 00:03:36 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Feb 2024 00:03:36 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code [v4] In-Reply-To: <9ezdxqyo0C-oR0r8bleXRJKI55qduwl9z3Lj2si_lpw=.46ae3241-62b3-489e-9342-ab10810e20d0@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> <9ezdxqyo0C-oR0r8bleXRJKI55qduwl9z3Lj2si_lpw=.46ae3241-62b3-489e-9342-ab10810e20d0@github.com> Message-ID: On Mon, 5 Feb 2024 21:51:02 GMT, Magnus Ihse Bursie wrote: >> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. >> >> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). >> >> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) >> >> Doing so has a dual benefit: >> >> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended >> >> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. >> >> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Restore period Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/11490#pullrequestreview-1863870608 From cjplummer at openjdk.org Tue Feb 6 00:03:45 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Feb 2024 00:03:45 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code [v4] In-Reply-To: References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Mon, 5 Feb 2024 16:53:33 GMT, Magnus Ihse Bursie wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore period > > src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27: > >> 25: >> 26: agent.err.error = ?? >> 27: agent.err.exception = ????? ????? ??????. > > I decided to remove the period here... I think it should probably stay, but this is really guess work. Would be nice to have a locale expert weigh in on this one. The reason I think it should stay is because it is a period at the end of a sentence vs a single word. Looking at some of the English entries sheds some light one this fact: agent.err.error = Error agent.err.exception = Exception thrown by the agent agent.err.warning = Warning agent.err.configfile.notfound = Config file not found agent.err.configfile.failed = Failed in reading the config file agent.err.configfile.closed.failed = Failed in closing the config file agent.err.configfile.access.denied = Access to the config file is denied Within this group, the error and warning entries are the only ones without a period (in the Korean version) and the only ones that are a single word instead of a sentence. However, I'm not sure why any of them have the period in the first place since the English version does not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11490#discussion_r1478829597 From ihse at openjdk.org Tue Feb 6 00:03:47 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 00:03:47 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code [v4] In-Reply-To: References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Mon, 5 Feb 2024 19:48:14 GMT, Chris Plummer wrote: >> src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27: >> >>> 25: >>> 26: agent.err.error = ?? >>> 27: agent.err.exception = ????? ????? ??????. >> >> I decided to remove the period here... > > I think it should probably stay, but this is really guess work. Would be nice to have a locale expert weigh in on this one. The reason I think it should stay is because it is a period at the end of a sentence vs a single word. Looking at some of the English entries sheds some light one this fact: > > > agent.err.error = Error > agent.err.exception = Exception thrown by the agent > agent.err.warning = Warning > > agent.err.configfile.notfound = Config file not found > agent.err.configfile.failed = Failed in reading the config file > agent.err.configfile.closed.failed = Failed in closing the config file > agent.err.configfile.access.denied = Access to the config file is denied > > > Within this group, the error and warning entries are the only ones without a period (in the Korean version) and the only ones that are a single word instead of a sentence. However, I'm not sure why any of them have the period in the first place since the English version does not. Ok, restored it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11490#discussion_r1478934863 From lmesnik at openjdk.org Tue Feb 6 02:56:58 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 6 Feb 2024 02:56:58 GMT Subject: RFR: 8325180: Rename jvmti_FollowRefObjects.h In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 16:34:19 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h > to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file. > > Testing: mach5 tier1 Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17689#pullrequestreview-1864190777 From iris at openjdk.org Tue Feb 6 03:11:03 2024 From: iris at openjdk.org (Iris Clark) Date: Tue, 6 Feb 2024 03:11:03 GMT Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC In-Reply-To: References: Message-ID: <4cRyPED3qle_BVYZkKe7WqzTTTypo6nFookYaFGeCDw=.a49cec00-d0b4-4f09-85f0-e5c2ce730792@github.com> On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote: > This update drops the "ea" from the version string. > > We also propagate the following fixes from the markdown sources to the troff manpage file: > > JDK-8322478: Update java manpage for multi-file source-code launcher > JDK-8302233: HSS/LMS: keytool and jarsigner changes > JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files > > > Thanks. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk22/pull/104#pullrequestreview-1864200734 From dholmes at openjdk.org Tue Feb 6 04:58:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Feb 2024 04:58:53 GMT Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 21:58:23 GMT, Joe Darcy wrote: >> This update drops the "ea" from the version string. >> >> We also propagate the following fixes from the markdown sources to the troff manpage file: >> >> JDK-8322478: Update java manpage for multi-file source-code launcher >> JDK-8302233: HSS/LMS: keytool and jarsigner changes >> JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files >> >> >> Thanks. > > Marked as reviewed by darcy (Reviewer). Thanks for the reviews @jddarcy and @irisclark ! ------------- PR Comment: https://git.openjdk.org/jdk22/pull/104#issuecomment-1928783920 From dholmes at openjdk.org Tue Feb 6 04:58:54 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Feb 2024 04:58:54 GMT Subject: [jdk22] Integrated: 8322066: Update troff manpages in JDK 22 before RC In-Reply-To: References: Message-ID: <43aREZ6MAFvrQojZi3ALfLy7yqlrS76R3HUs5lil8xE=.2471360a-6946-4dbc-91e8-386b5d31df58@github.com> On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote: > This update drops the "ea" from the version string. > > We also propagate the following fixes from the markdown sources to the troff manpage file: > > JDK-8322478: Update java manpage for multi-file source-code launcher > JDK-8302233: HSS/LMS: keytool and jarsigner changes > JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files > > > Thanks. This pull request has now been integrated. Changeset: ac7a3c00 Author: David Holmes URL: https://git.openjdk.org/jdk22/commit/ac7a3c00bbfde173ced08d8745b308bc0ac9649b Stats: 160 lines in 28 files changed: 63 ins; 15 del; 82 mod 8322066: Update troff manpages in JDK 22 before RC Reviewed-by: darcy, iris ------------- PR: https://git.openjdk.org/jdk22/pull/104 From sspitsyn at openjdk.org Tue Feb 6 05:45:00 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 6 Feb 2024 05:45:00 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v2] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository by a separate sub-task before integration of this update. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: thread in notify waiter list can't be BLOCKED ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/80225516..abe82a6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From mbaesken at openjdk.org Tue Feb 6 08:07:22 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Feb 2024 08:07:22 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken wrote: > > Thanks for the AIX related effort ; I put it again into our internal build/test queue. With the latest commit the build again fails on AIX with this error /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] result = fstatvfs(fd, &file_stat); ^~~~~~~~~~ /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here extern int fstatvfs(int, struct statvfs *); ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928972961 From ihse at openjdk.org Tue Feb 6 08:11:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:11:01 GMT Subject: Integrated: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. This pull request has now been integrated. Changeset: b02599d2 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/b02599d22e0f424a08045b32b94549c272fe35a7 Stats: 19 lines in 11 files changed: 0 ins; 0 del; 19 mod 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code Reviewed-by: cjplummer, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/11490 From ihse at openjdk.org Tue Feb 6 08:18:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:18:14 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also fix fstatvfs on AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/2de377cd..1fd34b10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Tue Feb 6 08:18:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:18:14 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v8] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:06:21 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Redefine statvfs as statvfs64 on AIX Yeah, I missed `fstatvfs`. ? Now, then maybe `n`th time's a charm? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928987789 From sroy at openjdk.org Tue Feb 6 08:45:12 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 6 Feb 2024 08:45:12 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: change control flow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/f4c1788b..14e0ed39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=13-14 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From mdoerr at openjdk.org Tue Feb 6 10:15:01 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 6 Feb 2024 10:15:01 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Tue, 6 Feb 2024 08:45:12 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > change control flow src/hotspot/os/aix/os_aix.cpp line 1178: > 1176: if (pointer_to_dot == nullptr) { > 1177: log_info(os)("Attempting to load a shared object without extension %s", filename); > 1178: return result; Memory leak: `file_path` not freed before returning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1479524411 From jkern at openjdk.org Tue Feb 6 10:28:59 2024 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 6 Feb 2024 10:28:59 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Tue, 6 Feb 2024 08:45:12 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > change control flow May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1929210294 From ihse at openjdk.org Tue Feb 6 11:39:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 11:39:57 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. @DougLea Doug, do you have anything to say about the changes in `java.util.concurrent`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1929336942 From coleenp at openjdk.org Tue Feb 6 13:29:01 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 Feb 2024 13:29:01 GMT Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into java while holding a lock In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 05:22:24 GMT, David Holmes wrote: >> This change uses a claim token to allocate multi dimensional arrays rather than holding MultiArray_lock around metaspace allocation. We can't hold a mutex around metaspace allocation because it can create an OOM object and it can also call into JVMTI for a resource exhausted event. Also, we were creating mirrors and more metadata arrays while holding this lock. See the bug for more details and other ideas considered and rejected. >> >> Tested with tier1-7. > > ~~Can't you just use a Monitor to implement the claim token, rather than this lock-free approach? (Similar to how class initialization is handled.)~~ > > Sorry lost the forest in the trees. I'm going to do a bit of rework as discussed with @dholmes-ora . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17660#issuecomment-1929599218 From coleenp at openjdk.org Tue Feb 6 13:29:02 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 Feb 2024 13:29:02 GMT Subject: Withdrawn: 8308745: ObjArrayKlass::allocate_objArray_klass may call into java while holding a lock In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 18:57:23 GMT, Coleen Phillimore wrote: > This change uses a claim token to allocate multi dimensional arrays rather than holding MultiArray_lock around metaspace allocation. We can't hold a mutex around metaspace allocation because it can create an OOM object and it can also call into JVMTI for a resource exhausted event. Also, we were creating mirrors and more metadata arrays while holding this lock. See the bug for more details and other ideas considered and rejected. > > Tested with tier1-7. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17660 From jsjolen at openjdk.org Tue Feb 6 13:34:54 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 6 Feb 2024 13:34:54 GMT Subject: RFR: 8322476: Remove GrowableArray C-Heap version, replace usages with GrowableArrayCHeap In-Reply-To: <7BF6OZ3vRH791MKbVeJqQ5foScHax_gLMFjSKkm3J68=.f29e5b1c-0751-4257-b253-261c6e20a7b9@github.com> References: <7BF6OZ3vRH791MKbVeJqQ5foScHax_gLMFjSKkm3J68=.f29e5b1c-0751-4257-b253-261c6e20a7b9@github.com> Message-ID: <0b-TYV3j49IRIUZzRDTDtDxniKa3PB-DqoAV8N3VpDs=.6d63d89a-0868-4b2a-9f42-024e42c54892@github.com> On Tue, 19 Dec 2023 16:59:05 GMT, Emanuel Peter wrote: > [JDK-8247755](https://bugs.openjdk.org/browse/JDK-8247755) introduced the `GrowableArrayCHeap`. This duplicates the current C-Heap allocation capability in `GrowableArray`. I now remove that from `GrowableArray` and move all usages to `GrowableArrayCHeap`. > > This has a few advantages: > - Clear separation between arena (and resource area) allocating array and C-heap allocating array. > - We can prevent assigning / copying between arrays of different allocation strategies already at compile time, and not only with asserts at runtime. > - We should not have multiple implementations of the same thing (C-Heap backed array). > - `GrowableArrayCHeap` is NONCOPYABLE. This is a nice restriction, we now know that C-Heap backed arrays do not get copied unknowingly. > > **Bonus** > We can now restrict `GrowableArray` element type `E` to be `std::is_trivially_destructible::value == true`. The idea is that arena / resource allocated arrays get abandoned, often without being even cleared. Hence, the elements in the array are never destructed. But if we only use elements that are trivially destructible, then it makes no difference if the destructors are ever called, or the elements simply abandoned. > > For `GrowableArrayCHeap`, we expect that the user eventually calls the destructor for the array, which in turn calls the destructors of the remaining elements. Hence, it is up to the user to ensure the cleanup. And so we can allow non-trivial destructors. > > **Testing** > Tier1-3 + stress testing: pending Not yet bot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17160#issuecomment-1929617168 From mbaesken at openjdk.org Tue Feb 6 14:01:00 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Feb 2024 14:01:00 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also fix fstatvfs on AIX AIX build is fixed now after latest commit, thanks for handling the AIX special cases. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1865270571 From ihse at openjdk.org Tue Feb 6 16:13:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 16:13:01 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also fix fstatvfs on AIX > > make/modules/jdk.hotspot.agent/Lib.gmk line 31: > >> 29: >> 30: ifeq ($(call isTargetOs, linux), true) >> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 > > We have two choices to feel a bit more comfortable: > 1) We unconditionally `static_assert` in a few places for large `off_t`, or > 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). > > Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. @thesamesam Do you want a `static_assert`? As I said, please let me know where you want to put it. I don't think it provides much, but if it makes you feel more comfortable, I'm okay with adding it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1480125790 From tschatzl at openjdk.org Tue Feb 6 16:29:55 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 6 Feb 2024 16:29:55 GMT Subject: RFR: 8323681: SA PointerFinder code should support G1 [v2] In-Reply-To: References: Message-ID: On Sat, 3 Feb 2024 04:28:24 GMT, Chris Plummer wrote: >> This PR adds G1 support to PointerFinder/PointerLocation. Previously we only had SerialGC support. Previously for G1 addresses SA would only report that the address is "In unknown section of Java heap" with no other details. Now it provides details for G1 addresses. Here are some examples for clhsdb `threadcontext` output. `threadcontext` dumps the contents of the thread's registers, some of which are often in the java heap. In the output below the first line is without verbose output and the 2nd is with: >> >> >> rbp: 0x00000000a0004080: In G1 heap region >> rbp: 0x00000000a0004080: In G1 heap Region: 0x00000000a0000000,0x00000000a0018a30,0x00000000a1000000:Old >> >> >> I also added an improvement to how SA deals with addresses in the TLAB. It used to only report that the address is in a TLAB and provide details about the TLAB in verbose mode. Now if verbose mode is used, the heap region information is included after the TLAB information. Here again is an example without and with verbose output: >> >> >> rsi: 0x0000000166000000: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f11c8029250 >> rsi: 0x0000000166000000: In TLAB for thread ("main" #1 prio=5 tid=0x00007f11c8029250 nid=1503 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_java >> ) [0x0000000166000000,0x00000001662d0c90,0x00000001667ffdc0,{0x0000000166800000}) >> In G1 heap Region: 0x0000000166000000,0x0000000166800000,0x0000000167000000:Eden >> >> >> Note at the end it indicates the address is in the Eden space, which is probably always the case for G1 TLAB addresses. For SerialGC is shows something similar. >> >> >> rsi: 0x0000000088ff99e0: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f0544029110 >> rsi: 0x0000000088ff99e0: In TLAB for thread ("main" #1 prio=5 tid=0x00007f0544029110 nid=3098 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_java >> ) [0x0000000088ff99e0,0x000000008978c090,0x0000000089ae54b0,{0x0000000089ae56f0}) >> In heap new generation: eden [0x0000000080200000,0x0000000089ae56f0,0x00000000a2420000) space capacity = 572653568, 27.99656213789626 used >> from [0x00000000a6860000,0x00000000a6860030,0x00000000aaca0000) space capacity = 71565312, 6.707160027472528E-5 used >> to [0x00000000a2420000,0x00000000a2420000,0x00000000a6860000) space capacity = 71565312, 0.0 used >> >> >> Testing all svc test in tier1, tier2, and tier5. Currently i... > > Chris Plummer has updated the pull request incrementally with three additional commits since the last revision: > > - Minor cleanup of output > - Don't assert if the address is in the G1 heap, but not in an region. Not all of the mapped part of the heap is in use by regions. > - Fix isInRegion() to check the entire region, not just the in use part. Seems good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17691#pullrequestreview-1865770223 From kevinw at openjdk.org Tue Feb 6 17:10:54 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Feb 2024 17:10:54 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl wrote: > 8307977: jcmd and jstack broken for target processes running with elevated capabilities Hi, Yes makes sense, this seems like an oversight that we were not consistent with the path. Does CAP_NET_BIND_SERVICE cause any issues for createAttachFile(int pid, int ns_pid) where it creates the .attach file in the current directory - it starts by trying "/proc/" + pid + "/cwd/" + ".attach_pid" + ns_pid, regardless of ns_pid. I'm curious if that always fails in the situation that causes the issue in this bug. If so looks like it would catch an IOException and then use findTargetProcessTmpDirectory, but wonder if we should predict it go straight there. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1930386568 From kbarrett at openjdk.org Tue Feb 6 17:19:20 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Feb 2024 17:19:20 GMT Subject: RFR: 8325180: Rename jvmti_FollowRefObjects.h [v2] In-Reply-To: References: Message-ID: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h > to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file. > > Testing: mach5 tier1 Kim Barrett 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 jvmti_FollowRefObjects - rename NULLs in jvmti_FollwRefObjects.hpp - rename jvmti_FollowRefObjects.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17689/files - new: https://git.openjdk.org/jdk/pull/17689/files/2fd44e24..bf1835b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17689&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17689&range=00-01 Stats: 5673 lines in 180 files changed: 3451 ins; 1256 del; 966 mod Patch: https://git.openjdk.org/jdk/pull/17689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17689/head:pull/17689 PR: https://git.openjdk.org/jdk/pull/17689 From kbarrett at openjdk.org Tue Feb 6 17:19:20 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Feb 2024 17:19:20 GMT Subject: RFR: 8325180: Rename jvmti_FollowRefObjects.h [v2] In-Reply-To: <6G5ULxx7CdvwKjmEIl0e3xwI6K-dYP3fWT0raVe6EV0=.35e20b87-1908-4ab6-9fb7-53d8a6e207f7@github.com> References: <6G5ULxx7CdvwKjmEIl0e3xwI6K-dYP3fWT0raVe6EV0=.35e20b87-1908-4ab6-9fb7-53d8a6e207f7@github.com> Message-ID: <-3uROA-4m1PcEKJwrR0BKj41LUODJcFTbhazJf89rIs=.789e6a5b-44e2-4440-a26c-7c03d74d8ab8@github.com> On Fri, 2 Feb 2024 17:49:22 GMT, Serguei Spitsyn wrote: >> Kim Barrett 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 jvmti_FollowRefObjects >> - rename NULLs in jvmti_FollwRefObjects.hpp >> - rename jvmti_FollowRefObjects.h > > Looks good. Thanks for reviews, @sspitsyn , @lmesnik , and @TheShermanTanker . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17689#issuecomment-1930397715 From kbarrett at openjdk.org Tue Feb 6 17:19:21 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Feb 2024 17:19:21 GMT Subject: Integrated: 8325180: Rename jvmti_FollowRefObjects.h In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 16:34:19 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.h > to jvmti_FollowRefObjects.hpp, and replaces uses of NULL in the file. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 2d252ee0 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/2d252ee06e8d620c3048e4556079b402f4472a32 Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod 8325180: Rename jvmti_FollowRefObjects.h Reviewed-by: sspitsyn, jwaters, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/17689 From kevinw at openjdk.org Tue Feb 6 17:41:58 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Feb 2024 17:41:58 GMT Subject: RFR: 8323681: SA PointerFinder code should support G1 [v2] In-Reply-To: References: Message-ID: On Sat, 3 Feb 2024 04:28:24 GMT, Chris Plummer wrote: >> This PR adds G1 support to PointerFinder/PointerLocation. Previously we only had SerialGC support. Previously for G1 addresses SA would only report that the address is "In unknown section of Java heap" with no other details. Now it provides details for G1 addresses. Here are some examples for clhsdb `threadcontext` output. `threadcontext` dumps the contents of the thread's registers, some of which are often in the java heap. In the output below the first line is without verbose output and the 2nd is with: >> >> >> rbp: 0x00000000a0004080: In G1 heap region >> rbp: 0x00000000a0004080: In G1 heap Region: 0x00000000a0000000,0x00000000a0018a30,0x00000000a1000000:Old >> >> >> I also added an improvement to how SA deals with addresses in the TLAB. It used to only report that the address is in a TLAB and provide details about the TLAB in verbose mode. Now if verbose mode is used, the heap region information is included after the TLAB information. Here again is an example without and with verbose output: >> >> >> rsi: 0x0000000166000000: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f11c8029250 >> rsi: 0x0000000166000000: In TLAB for thread ("main" #1 prio=5 tid=0x00007f11c8029250 nid=1503 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_java >> ) [0x0000000166000000,0x00000001662d0c90,0x00000001667ffdc0,{0x0000000166800000}) >> In G1 heap Region: 0x0000000166000000,0x0000000166800000,0x0000000167000000:Eden >> >> >> Note at the end it indicates the address is in the Eden space, which is probably always the case for G1 TLAB addresses. For SerialGC is shows something similar. >> >> >> rsi: 0x0000000088ff99e0: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f0544029110 >> rsi: 0x0000000088ff99e0: In TLAB for thread ("main" #1 prio=5 tid=0x00007f0544029110 nid=3098 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_java >> ) [0x0000000088ff99e0,0x000000008978c090,0x0000000089ae54b0,{0x0000000089ae56f0}) >> In heap new generation: eden [0x0000000080200000,0x0000000089ae56f0,0x00000000a2420000) space capacity = 572653568, 27.99656213789626 used >> from [0x00000000a6860000,0x00000000a6860030,0x00000000aaca0000) space capacity = 71565312, 6.707160027472528E-5 used >> to [0x00000000a2420000,0x00000000a2420000,0x00000000a6860000) space capacity = 71565312, 0.0 used >> >> >> Testing all svc test in tier1, tier2, and tier5. Currently i... > > Chris Plummer has updated the pull request incrementally with three additional commits since the last revision: > > - Minor cleanup of output > - Don't assert if the address is in the G1 heap, but not in an region. Not all of the mapped part of the heap is in use by regions. > - Fix isInRegion() to check the entire region, not just the in use part. Looks good to me. Trivia on the output formatting: For serial, an object not in a tlab, without verbose, I think it prints "In heap new generation:" and then nothing else. The ":" leaves you hanging thinking it should introduce something else, so there must have been a problem showing the something else. 8-) Maybe we should just remove the 3 colons from the serial gen printing, then we have that it looked like before? (or hold on until we are in "if (verbose)" if we want to add them) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17691#pullrequestreview-1865959422 From cjplummer at openjdk.org Tue Feb 6 19:24:04 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Feb 2024 19:24:04 GMT Subject: RFR: 8323681: SA PointerFinder code should support G1 [v3] In-Reply-To: References: Message-ID: > This PR adds G1 support to PointerFinder/PointerLocation. Previously we only had SerialGC support. Previously for G1 addresses SA would only report that the address is "In unknown section of Java heap" with no other details. Now it provides details for G1 addresses. Here are some examples for clhsdb `threadcontext` output. `threadcontext` dumps the contents of the thread's registers, some of which are often in the java heap. In the output below the first line is without verbose output and the 2nd is with: > > > rbp: 0x00000000a0004080: In G1 heap region > rbp: 0x00000000a0004080: In G1 heap Region: 0x00000000a0000000,0x00000000a0018a30,0x00000000a1000000:Old > > > I also added an improvement to how SA deals with addresses in the TLAB. It used to only report that the address is in a TLAB and provide details about the TLAB in verbose mode. Now if verbose mode is used, the heap region information is included after the TLAB information. Here again is an example without and with verbose output: > > > rsi: 0x0000000166000000: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f11c8029250 > rsi: 0x0000000166000000: In TLAB for thread ("main" #1 prio=5 tid=0x00007f11c8029250 nid=1503 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_java > ) [0x0000000166000000,0x00000001662d0c90,0x00000001667ffdc0,{0x0000000166800000}) > In G1 heap Region: 0x0000000166000000,0x0000000166800000,0x0000000167000000:Eden > > > Note at the end it indicates the address is in the Eden space, which is probably always the case for G1 TLAB addresses. For SerialGC is shows something similar. > > > rsi: 0x0000000088ff99e0: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f0544029110 > rsi: 0x0000000088ff99e0: In TLAB for thread ("main" #1 prio=5 tid=0x00007f0544029110 nid=3098 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_java > ) [0x0000000088ff99e0,0x000000008978c090,0x0000000089ae54b0,{0x0000000089ae56f0}) > In heap new generation: eden [0x0000000080200000,0x0000000089ae56f0,0x00000000a2420000) space capacity = 572653568, 27.99656213789626 used > from [0x00000000a6860000,0x00000000a6860030,0x00000000aaca0000) space capacity = 71565312, 6.707160027472528E-5 used > to [0x00000000a2420000,0x00000000a2420000,0x00000000a6860000) space capacity = 71565312, 0.0 used > > > Testing all svc test in tier1, tier2, and tier5. Currently in progress. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Get rid of trailing colon for SerialGC terse output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17691/files - new: https://git.openjdk.org/jdk/pull/17691/files/37b3f17b..eca6031e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17691&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17691&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17691/head:pull/17691 PR: https://git.openjdk.org/jdk/pull/17691 From cjplummer at openjdk.org Tue Feb 6 19:24:04 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Feb 2024 19:24:04 GMT Subject: RFR: 8323681: SA PointerFinder code should support G1 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 17:39:42 GMT, Kevin Walls wrote: > Trivia on the output formatting: For serial, an object not in a tlab, without verbose, I think it prints "In heap new generation:" and then nothing else. The ":" leaves you hanging thinking it should introduce something else, so there must have been a problem showing the something else. 8-) > > Maybe we should just remove the 3 colons from the serial gen printing, then we have that it looked like before? (or hold on until we are in "if (verbose)" if we want to add them) Ok, I've made that change. You now only get the colon during verbose output. Note that gen.priontOn() prints a leading space, so no need to put a space explicitly after the colon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17691#issuecomment-1930604728 From kbarrett at openjdk.org Tue Feb 6 22:13:09 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Feb 2024 22:13:09 GMT Subject: RFR: 8325347: Rename native_thread.h Message-ID: Please review this trivial change that renames the file test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h to native_thread.hpp. and replaces uses of NULL in that file. Testing: mach5 tier1 ------------- Commit messages: - rename NULLs in native_thread.hpp - rename native_thread.h Changes: https://git.openjdk.org/jdk/pull/17737/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17737&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325347 Stats: 171 lines in 14 files changed: 78 ins; 78 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/17737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17737/head:pull/17737 PR: https://git.openjdk.org/jdk/pull/17737 From coleenp at openjdk.org Tue Feb 6 22:32:53 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 Feb 2024 22:32:53 GMT Subject: RFR: 8325347: Rename native_thread.h In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 22:08:18 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h > to native_thread.hpp. and replaces uses of NULL in that file. > > Testing: mach5 tier1 Agree this looks trivial, if tests complete. edit: I think the test build would fail if one of these .h includes was missed. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17737#pullrequestreview-1866446137 From lmesnik at openjdk.org Tue Feb 6 23:07:59 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 6 Feb 2024 23:07:59 GMT Subject: RFR: 8325347: Rename native_thread.h In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 22:08:18 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h > to native_thread.hpp. and replaces uses of NULL in that file. > > Testing: mach5 tier1 Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17737#pullrequestreview-1866483869 From kbarrett at openjdk.org Tue Feb 6 23:46:57 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Feb 2024 23:46:57 GMT Subject: RFR: 8325347: Rename native_thread.h In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 22:30:18 GMT, Coleen Phillimore wrote: >> Please review this trivial change that renames the file >> test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h >> to native_thread.hpp. and replaces uses of NULL in that file. >> >> Testing: mach5 tier1 > > Agree this looks trivial, if tests complete. > > edit: I think the test build would fail if one of these .h includes was missed. Thanks for reviews, @coleenp and @lmesnik . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17737#issuecomment-1930952491 From kbarrett at openjdk.org Tue Feb 6 23:46:58 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Feb 2024 23:46:58 GMT Subject: Integrated: 8325347: Rename native_thread.h In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 22:08:18 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h > to native_thread.hpp. and replaces uses of NULL in that file. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: f2f63444 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/f2f634448e2095f2be1c220d7c10355ab4888439 Stats: 171 lines in 14 files changed: 78 ins; 78 del; 15 mod 8325347: Rename native_thread.h Reviewed-by: coleenp, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/17737 From duke at openjdk.org Wed Feb 7 05:58:55 2024 From: duke at openjdk.org (Taizo Kurashige) Date: Wed, 7 Feb 2024 05:58:55 GMT Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump [v3] In-Reply-To: References: <4AmewOHYpmDuaD4H4sk9wb2z6EsQwJinORtc73FCIX0=.ea07369a-c8b0-4c99-8fe0-32ad8ffb9300@github.com> Message-ID: <32H_yPlBxdBuPqBbLt53dwE38WnT0RLyy18qsrIMMZI=.6f655a85-be78-4bf9-8b9a-7058bb921fdd@github.com> On Thu, 1 Feb 2024 05:07:13 GMT, David Holmes wrote: >> @dholmes-ora @egahlin >> >> I'm sorry that my slow response has prolonged this issue. I created a subtask and modified the source. If possible, please review them. > > Thanks @kurashige23 , the manpage subtask will be handled by someone from Oracle. I'll leave it to JFR folk to do the review here. Thanks @dholmes-ora , I understood that the subtask will be handled by someone from Oracle. > I'll leave it to JFR folk to do the review here. Does it mean that this pull request will not be merged until the subtask is resolved? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16413#issuecomment-1931341003 From sspitsyn at openjdk.org Wed Feb 7 07:02:11 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Feb 2024 07:02:11 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn 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 - review: thread in notify waiter list can't be BLOCKED - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/abe82a6c..3d735722 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=01-02 Stats: 7346 lines in 273 files changed: 4294 ins; 1478 del; 1574 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From ihse at openjdk.org Wed Feb 7 15:53:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 Feb 2024 15:53:59 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Just to confirm publicly, there is no need for any special handling of `java.util.concurrent` any longer; the JDK repo is the single source of truth nowadays. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1932335281 From ihse at openjdk.org Wed Feb 7 15:53:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 Feb 2024 15:53:59 GMT Subject: Integrated: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. This pull request has now been integrated. Changeset: 18e24d06 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/18e24d0619ffef7c6dbfc419105faba9f7ba1874 Stats: 61 lines in 39 files changed: 0 ins; 0 del; 61 mod 8325109: Sort method modifiers in canonical order Reviewed-by: aivanov, rriggs, darcy, prappo ------------- PR: https://git.openjdk.org/jdk/pull/17670 From jkern at openjdk.org Wed Feb 7 15:56:00 2024 From: jkern at openjdk.org (Joachim Kern) Date: Wed, 7 Feb 2024 15:56:00 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also fix fstatvfs on AIX My apologies the additional defines `#define DIR DIR64` `#define dirent dirent64` `#define opendir opendir64` `#define readdir readdir64` `#define closedir closedir64` are not necessary. Indeed they do not react on _LARGE_FILES, but the DIR struct and the functions are automatically 64 when compiling in 64bit mode (-m64) as we do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1932343048 From kbarrett at openjdk.org Wed Feb 7 20:53:10 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 7 Feb 2024 20:53:10 GMT Subject: RFR: 8325367: Rename nsk_list.h Message-ID: <12ElhTsHI87z86lOMcYKu7Cb6CF2CMykgWDYkDNKHyU=.703da88e-06ef-44cb-8030-c4e7237e94d6@github.com> Please review this trivial change that renames the file test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.h to nsk_list.hpp. Testing: mach5 tier1 Note that build would fail if #include updates were incorrect or incomplete. ------------- Commit messages: - rename nsk_list.h Changes: https://git.openjdk.org/jdk/pull/17758/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17758&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325367 Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17758/head:pull/17758 PR: https://git.openjdk.org/jdk/pull/17758 From amenkov at openjdk.org Wed Feb 7 20:59:16 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 7 Feb 2024 20:59:16 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow Message-ID: The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. testing: - sanity tier1; - all RedefineClasses/RetransformClasses 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 ------------- Commit messages: - merge_cp_length overflow check Changes: https://git.openjdk.org/jdk/pull/17759/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17759&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311076 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17759/head:pull/17759 PR: https://git.openjdk.org/jdk/pull/17759 From coleenp at openjdk.org Wed Feb 7 22:03:54 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Feb 2024 22:03:54 GMT Subject: RFR: 8325367: Rename nsk_list.h In-Reply-To: <12ElhTsHI87z86lOMcYKu7Cb6CF2CMykgWDYkDNKHyU=.703da88e-06ef-44cb-8030-c4e7237e94d6@github.com> References: <12ElhTsHI87z86lOMcYKu7Cb6CF2CMykgWDYkDNKHyU=.703da88e-06ef-44cb-8030-c4e7237e94d6@github.com> Message-ID: On Wed, 7 Feb 2024 20:48:18 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.h to nsk_list.hpp. > > Testing: mach5 tier1 > Note that build would fail if #include updates were incorrect or incomplete. Yes, it's trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17758#pullrequestreview-1868882877 From dcubed at openjdk.org Wed Feb 7 23:03:58 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Feb 2024 23:03:58 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 07:02:11 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn 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 > - review: thread in notify waiter list can't be BLOCKED > - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage Okay... so we might have an incorrect implementation of JVM TI GetObjectMonitorUsage, but I'm not convinced that it is broken in the way that we think it is broken. Please read thru my unfortunately long comments on the complicated logic in `JvmtiEnvBase::get_object_monitor_usage()`. I _think_ things are broken in a different way than what we're talking about in this bug. In particular, the logic that populates the `waiters` array and reduces the `waiter_count` value overrides the value that we think we're fixing in the beginning of the function. Similarly, the logic that populates the `notify_waiters` array and reduces the `notify_waiter_count` value also overrides the value that we think we're fixing in the beginning of the function. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1489: > 1487: nWait = mon->waiters(); // # of threads in Object.wait() > 1488: ret.waiter_count = nWant; > 1489: ret.notify_waiter_count = nWait; Please note that the comment on L1487 is accurate. The `waiters` count is incremented just before the thread that has called `wait()` drops the monitor and that increased count remains in effect until after the thread has reentered the monitor after being notified or the wait timeout has expired. The `contentions` count is not incremented in the re-entry path so a thread that is in `wait()` that has been notified or the wait timeout has expired is not counted as a contending thread. So if we really want the `waiter_count` field to include threads that have been notified or the wait timeout has expired, then we have to add some logic to carefully increment the `contentions` count. This old logic: ``` ret.waiter_count = nWant + nWait;``` over counts because it also includes threads in `wait()` that have not yet been notified and the wait timeout has not expired. However, including `nWait` is correct for the situation when all of the waiting threads have been notified or their wait timeouts have expired. This also means that `nWait` and the `ret.notify_waiter_count` value are over counting waiters because that value will include threads that (have been notified or the wait timeout has expired) AND have not reentered the monitor. I _think_ we're saying that is NOT what we want. However, I _think_ that the `nWait` value is fixed below when we're gathering up the list of waiters. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1521: > 1519: // we have contending and/or waiting threads > 1520: if (nWant > 0) { > 1521: // we have contending threads This block includes this logic: // get_pending_threads returns only java thread so we do not need to // check for non java threads. GrowableArray* wantList = Threads::get_pending_threads(tlh.list(), nWant, (address)mon); if (wantList->length() < nWant) { // robustness: the pending list has gotten smaller nWant = wantList->length(); } `Threads::get_pending_threads()` only returns threads where the `current_pending_monitor` field is set for the specific monitor. That happens only on contended enter and does not happen on contended re-enter so this logic will already strip out any threads in `wait()` that have not been notified and have not had their wait timers expire. It will also strip out any waiters that have been notified or had their wait timeouts expire. This means even if we fix the reenter code to increment the contentions field, this logic will reduce that `nWant` value. Of course, the way around that is to also update the reenter code to properly set the `current_pending_monitor` field and then the reentering threads won't be filtered out... src/hotspot/share/prims/jvmtiEnvBase.cpp line 1560: > 1558: // Adjust count. nWant and nWait count values may be less than original. > 1559: ret.waiter_count = nWant; > 1560: ret.notify_waiter_count = nWait; This old logic: ``` ret.waiter_count = nWant + nWait;``` over counts because it also includes threads in wait() that have not yet been notified and the wait timeout has not expired. However, including nWait is correct for the situation when all of the waiting threads have been notified or their wait timeouts have expired. If we have fixed the increment of contentions like the comment above mentions, then `nWant` will properly reflect the semantics that I think we're talking about. When we're gathering up the entries for `waiters` above, we traverse the list of waiters and we reduce the `nWait` when the list is shorter than what we expected earlier. See L1540 -> L1544. test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp line 95: > 93: > 94: JNIEXPORT void JNICALL > 95: Java_nsk_jvmti_GetObjectMonitorUsage_objmonusage001_check(JNIEnv *env, I would have expected a modification to an objmonusage001.java file to update the parameters to that test's `check()` function. test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp line 161: > 159: > 160: if (inf.notify_waiter_count != notifyWaiterCount) { > 161: printf("(%d) waiter_count expected: %d, actually: %d\n", nit typo: s/waiter_count/notify_waiter_count/ test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/objmonusage003.cpp line 150: > 148: > 149: if (inf.notify_waiter_count != notifyWaiterCount) { > 150: printf("(%d) waiter_count expected: %d, actually: %d\n", nit typo: s/waiter_count/notify_waiter_count/ ------------- Changes requested by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1868875636 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482144591 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482180688 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482155914 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482189539 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482185062 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482185460 From cjplummer at openjdk.org Wed Feb 7 23:41:56 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Feb 2024 23:41:56 GMT Subject: RFR: 8323681: SA PointerFinder code should support G1 [v3] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 19:24:04 GMT, Chris Plummer wrote: >> This PR adds G1 support to PointerFinder/PointerLocation. Previously we only had SerialGC support. Previously for G1 addresses SA would only report that the address is "In unknown section of Java heap" with no other details. Now it provides details for G1 addresses. Here are some examples for clhsdb `threadcontext` output. `threadcontext` dumps the contents of the thread's registers, some of which are often in the java heap. In the output below the first line is without verbose output and the 2nd is with: >> >> >> rbp: 0x00000000a0004080: In G1 heap region >> rbp: 0x00000000a0004080: In G1 heap Region: 0x00000000a0000000,0x00000000a0018a30,0x00000000a1000000:Old >> >> >> I also added an improvement to how SA deals with addresses in the TLAB. It used to only report that the address is in a TLAB and provide details about the TLAB in verbose mode. Now if verbose mode is used, the heap region information is included after the TLAB information. Here again is an example without and with verbose output: >> >> >> rsi: 0x0000000166000000: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f11c8029250 >> rsi: 0x0000000166000000: In TLAB for thread ("main" #1 prio=5 tid=0x00007f11c8029250 nid=1503 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_java >> ) [0x0000000166000000,0x00000001662d0c90,0x00000001667ffdc0,{0x0000000166800000}) >> In G1 heap Region: 0x0000000166000000,0x0000000166800000,0x0000000167000000:Eden >> >> >> Note at the end it indicates the address is in the Eden space, which is probably always the case for G1 TLAB addresses. For SerialGC is shows something similar. >> >> >> rsi: 0x0000000088ff99e0: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f0544029110 >> rsi: 0x0000000088ff99e0: In TLAB for thread ("main" #1 prio=5 tid=0x00007f0544029110 nid=3098 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_java >> ) [0x0000000088ff99e0,0x000000008978c090,0x0000000089ae54b0,{0x0000000089ae56f0}) >> In heap new generation: eden [0x0000000080200000,0x0000000089ae56f0,0x00000000a2420000) space capacity = 572653568, 27.99656213789626 used >> from [0x00000000a6860000,0x00000000a6860030,0x00000000aaca0000) space capacity = 71565312, 6.707160027472528E-5 used >> to [0x00000000a2420000,0x00000000a2420000,0x00000000a6860000) space capacity = 71565312, 0.0 used >> >> >> Testing all svc test in tier1, tier2, and tier5. Currently i... > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of trailing colon for SerialGC terse output Thanks for the reviews Thomas and Kevin! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17691#issuecomment-1933119334 From cjplummer at openjdk.org Wed Feb 7 23:41:57 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Feb 2024 23:41:57 GMT Subject: Integrated: 8323681: SA PointerFinder code should support G1 In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:24:20 GMT, Chris Plummer wrote: > This PR adds G1 support to PointerFinder/PointerLocation. Previously we only had SerialGC support. Previously for G1 addresses SA would only report that the address is "In unknown section of Java heap" with no other details. Now it provides details for G1 addresses. Here are some examples for clhsdb `threadcontext` output. `threadcontext` dumps the contents of the thread's registers, some of which are often in the java heap. In the output below the first line is without verbose output and the 2nd is with: > > > rbp: 0x00000000a0004080: In G1 heap region > rbp: 0x00000000a0004080: In G1 heap Region: 0x00000000a0000000,0x00000000a0018a30,0x00000000a1000000:Old > > > I also added an improvement to how SA deals with addresses in the TLAB. It used to only report that the address is in a TLAB and provide details about the TLAB in verbose mode. Now if verbose mode is used, the heap region information is included after the TLAB information. Here again is an example without and with verbose output: > > > rsi: 0x0000000166000000: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f11c8029250 > rsi: 0x0000000166000000: In TLAB for thread ("main" #1 prio=5 tid=0x00007f11c8029250 nid=1503 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_java > ) [0x0000000166000000,0x00000001662d0c90,0x00000001667ffdc0,{0x0000000166800000}) > In G1 heap Region: 0x0000000166000000,0x0000000166800000,0x0000000167000000:Eden > > > Note at the end it indicates the address is in the Eden space, which is probably always the case for G1 TLAB addresses. For SerialGC is shows something similar. > > > rsi: 0x0000000088ff99e0: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007f0544029110 > rsi: 0x0000000088ff99e0: In TLAB for thread ("main" #1 prio=5 tid=0x00007f0544029110 nid=3098 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_java > ) [0x0000000088ff99e0,0x000000008978c090,0x0000000089ae54b0,{0x0000000089ae56f0}) > In heap new generation: eden [0x0000000080200000,0x0000000089ae56f0,0x00000000a2420000) space capacity = 572653568, 27.99656213789626 used > from [0x00000000a6860000,0x00000000a6860030,0x00000000aaca0000) space capacity = 71565312, 6.707160027472528E-5 used > to [0x00000000a2420000,0x00000000a2420000,0x00000000a6860000) space capacity = 71565312, 0.0 used > > > Testing all svc test in tier1, tier2, and tier5. Currently in progress. This pull request has now been integrated. Changeset: be7cc1c2 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/be7cc1c2b083ac7cbcec6b0fe77caff16f14bb60 Stats: 73 lines in 4 files changed: 57 ins; 6 del; 10 mod 8323681: SA PointerFinder code should support G1 Reviewed-by: tschatzl, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/17691 From kbarrett at openjdk.org Thu Feb 8 00:02:58 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 8 Feb 2024 00:02:58 GMT Subject: RFR: 8325367: Rename nsk_list.h In-Reply-To: References: <12ElhTsHI87z86lOMcYKu7Cb6CF2CMykgWDYkDNKHyU=.703da88e-06ef-44cb-8030-c4e7237e94d6@github.com> Message-ID: On Wed, 7 Feb 2024 22:01:13 GMT, Coleen Phillimore wrote: >> Please review this trivial change that renames the file >> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.h to nsk_list.hpp. >> >> Testing: mach5 tier1 >> Note that build would fail if #include updates were incorrect or incomplete. > > Yes, it's trivial. Thanks for review, @coleenp ------------- PR Comment: https://git.openjdk.org/jdk/pull/17758#issuecomment-1933136159 From kbarrett at openjdk.org Thu Feb 8 00:02:59 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 8 Feb 2024 00:02:59 GMT Subject: Integrated: 8325367: Rename nsk_list.h In-Reply-To: <12ElhTsHI87z86lOMcYKu7Cb6CF2CMykgWDYkDNKHyU=.703da88e-06ef-44cb-8030-c4e7237e94d6@github.com> References: <12ElhTsHI87z86lOMcYKu7Cb6CF2CMykgWDYkDNKHyU=.703da88e-06ef-44cb-8030-c4e7237e94d6@github.com> Message-ID: On Wed, 7 Feb 2024 20:48:18 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.h to nsk_list.hpp. > > Testing: mach5 tier1 > Note that build would fail if #include updates were incorrect or incomplete. This pull request has now been integrated. Changeset: 9cccf051 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/9cccf0515e5a8449fa4a5a89f1935e206e465f39 Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod 8325367: Rename nsk_list.h Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/jdk/pull/17758 From duke at openjdk.org Thu Feb 8 04:44:02 2024 From: duke at openjdk.org (Sam James) Date: Thu, 8 Feb 2024 04:44:02 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> Message-ID: On Fri, 2 Feb 2024 15:49:59 GMT, Magnus Ihse Bursie wrote: >> I wrote earlier: >> >>> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.) > > Basically, my understanding is that a call to "openat" in the source file will be converted into a call to openat64 on 32-bit platforms. When we look up the function using dlsym, I assume we need to find the 64-bit version directly. > > Even if this is incorrect, it seems at least *safe* to do it this way. The redirection is done via aliases in the headers, so you're right. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1482403071 From lmesnik at openjdk.org Thu Feb 8 05:43:05 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 Feb 2024 05:43:05 GMT Subject: RFR: 8316460: 4 javax/management tests ignore VM flags Message-ID: The tests javax/management/ImplementationVersion/ImplVersionTest.java javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java javax/management/remote/mandatory/version/ImplVersionTest.java javax/management/security/HashedPasswordFileTest.java were updated to use ProcessTools.createTestJavaProcessBuilder(...) Tested by running tests with different jvm flags and tier1. ------------- Commit messages: - 8316460: 4 javax/management tests ignore VM flags Changes: https://git.openjdk.org/jdk/pull/17764/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17764&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316460 Stats: 132 lines in 5 files changed: 12 ins; 59 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/17764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17764/head:pull/17764 PR: https://git.openjdk.org/jdk/pull/17764 From duke at openjdk.org Thu Feb 8 06:24:05 2024 From: duke at openjdk.org (Yifeng Jin) Date: Thu, 8 Feb 2024 06:24:05 GMT Subject: RFR: 8325464: GCCause.java out of sync with gcCause.hpp Message-ID: This patch updates `GCCause.java` to keep sync with latest `gcCause.hpp`. ------------- Commit messages: - GCCause.java out of sync with gcCause.hpp Changes: https://git.openjdk.org/jdk/pull/17766/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17766&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325464 Stats: 10 lines in 1 file changed: 5 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17766/head:pull/17766 PR: https://git.openjdk.org/jdk/pull/17766 From dholmes at openjdk.org Thu Feb 8 07:07:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Feb 2024 07:07:55 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 07:02:11 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn 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 > - review: thread in notify waiter list can't be BLOCKED > - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage Based on Dan's analysis I would have to go back and redo the complete analysis for myself. :( I think the only way to make sense of this is to actually set up scenarios where we have different threads contending on entry, different threads waiting and different threads re-entering after being notified, and see what values actually get returned in each case. I think the `pending_current_monitor` issue may be a distinct/different issue. I can easily imagine that this was overlooked when we introduced the "wait morphing" rather than have the notified/timed-out/interrupted waiters actually place themselves on the entry queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1933469232 From ihse at openjdk.org Thu Feb 8 07:44:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Feb 2024 07:44:18 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Once more, remove AIX dirent64 et al defines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/1fd34b10..8a71e3b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=08-09 Stats: 44 lines in 7 files changed: 0 ins; 44 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From duke at openjdk.org Thu Feb 8 07:44:18 2024 From: duke at openjdk.org (Sam James) Date: Thu, 8 Feb 2024 07:44:18 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:41:02 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Once more, remove AIX dirent64 et al defines Marked as reviewed by thesamesam at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1869449960 From ihse at openjdk.org Thu Feb 8 07:44:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Feb 2024 07:44:18 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote: >>> I hope finally the AIX part of this PR is done. >> >> Thanks for the AIX related effort ; I put it again into our internal build/test queue. > >> >> Thanks for the AIX related effort ; I put it again into our internal build/test queue. > > With the latest commit the build again fails on AIX with this error > > /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] > result = fstatvfs(fd, &file_stat); > ^~~~~~~~~~ > /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here > extern int fstatvfs(int, struct statvfs *); Well, well... The code at least looks cleaner without these AIX defines, so I really hope that this is the end of the AIX saga, at the `n+1`th time. @MBaesken Can you rerun AIX testing with the latest commit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933513366 From duke at openjdk.org Thu Feb 8 07:44:18 2024 From: duke at openjdk.org (Sam James) Date: Thu, 8 Feb 2024 07:44:18 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: <7tII90EgHAAJH2eHwSx0CFV5smD9VXSUx5ffVtUtnWc=.c39a6845-2f40-4c57-bd0e-200cf77ccb28@github.com> On Tue, 6 Feb 2024 16:10:38 GMT, Magnus Ihse Bursie wrote: >> make/modules/jdk.hotspot.agent/Lib.gmk line 31: >> >>> 29: >>> 30: ifeq ($(call isTargetOs, linux), true) >>> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 >> >> We have two choices to feel a bit more comfortable: >> 1) We unconditionally `static_assert` in a few places for large `off_t`, or >> 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). >> >> Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. > > @thesamesam Do you want a `static_assert`? As I said, please let me know where you want to put it. I don't think it provides much, but if it makes you feel more comfortable, I'm okay with adding it. Sorry! I think I'm okay with it as-is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1482529665 From duke at openjdk.org Thu Feb 8 08:37:54 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Thu, 8 Feb 2024 08:37:54 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 17:08:43 GMT, Kevin Walls wrote: > Does CAP_NET_BIND_SERVICE cause any issues for createAttachFile(int pid, int ns_pid) where it creates the .attach file in the current directory - it starts by trying "/proc/" + pid + "/cwd/" + ".attach_pid" + ns_pid, regardless of ns_pid. > > I'm curious if that always fails in the situation that causes the issue in this bug. If so looks like it would catch an IOException and then use findTargetProcessTmpDirectory, but wonder if we should predict it go straight there. Hi @kevinjwalls, and thank you for taking a look! To make sure we're on the same page, is what you are asking if something like this would make sense (on top of the current state of the PR)? diff --git src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java index 81d4fd259ed..c06c972b39a 100644 --- src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java +++ src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java @@ -221,16 +221,19 @@ private File findSocketFile(int pid, int ns_pid) throws IOException { // checks for the file. private File createAttachFile(int pid, int ns_pid) throws IOException { String fn = ".attach_pid" + ns_pid; - String path = "/proc/" + pid + "/cwd/" + fn; - File f = new File(path); - try { - // Do not canonicalize the file path, or we will fail to attach to a VM in a container. - f.createNewFile(); - } catch (IOException x) { + + File f; + if (pid != ns_pid) { + String path = "/proc/" + pid + "/cwd/" + fn; + f = new File(path); + } else { String root = findTargetProcessTmpDirectory(pid, ns_pid); f = new File(root, fn); - f.createNewFile(); } + + // Do not canonicalize the file path, or we will fail to attach to a VM in a container. + f.createNewFile(); + return f; } That is, if we know that `pid` and `ns_pid` are equal, do not even try to create the file in `/proc//cwd`. That's a good question. I tried to minimize the changes because I'm so unfamiliar with JDK internals and also don't have a good understanding of all the different use-cases that need to work. I tried out the diff above locally using the reproducer steps from https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081. It seems to work equally fine in the case of a systemd unit using `AmbientCapabilities=CAP_NET_BIND_SERVICE`, and also in the case of attaching against a JVM running inside a Docker container. The `test/hotspot/jtreg/containers` and `test/hotspot/jtreg/serviceability` tests all pass too. That said, I'm still more confident in the current state of the PR, as it more closely follows what has existed before. But if you believe that this is a better way of handling it, I'm fine with that too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1933588889 From stefank at openjdk.org Thu Feb 8 08:42:53 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Feb 2024 08:42:53 GMT Subject: RFR: 8325464: GCCause.java out of sync with gcCause.hpp In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 06:19:16 GMT, Yifeng Jin wrote: > These two files (`GCCause.java` and `gcCause.hpp`) should be in sync by design, see comments in these two files. However, some recent changes (e.g. [JDK-8240239](https://bugs.openjdk.org/browse/JDK-8240239)) to `gcCause.hpp` were not simultaneously reflected in `GCCause.java`. This patch updates `GCCause.java` to keep sync with latest `gcCause.hpp`. Changes requested by stefank (Reviewer). src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java line 65: > 63: _z_allocation_stall ("Allocation Stall"), > 64: _z_proactive ("Proactive"), > 65: _z_high_usage ("High Usage"), gcCause.hpp has the Shenandoah and ZGC blocks swapped. Could you fix it in this change as well? ------------- PR Review: https://git.openjdk.org/jdk/pull/17766#pullrequestreview-1869553109 PR Review Comment: https://git.openjdk.org/jdk/pull/17766#discussion_r1482599594 From jkern at openjdk.org Thu Feb 8 09:06:03 2024 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 8 Feb 2024 09:06:03 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Once more, remove AIX dirent64 et al defines And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933630674 From mbaesken at openjdk.org Thu Feb 8 09:20:00 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 8 Feb 2024 09:20:00 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <5GBUr8CF3X7ZZYPezmBQUzuWQZuk-pXRrdkS4PX6zeE=.28790345-6e6a-4b10-8767-1b3f8b44754b@github.com> On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote: >>> I hope finally the AIX part of this PR is done. >> >> Thanks for the AIX related effort ; I put it again into our internal build/test queue. > >> >> Thanks for the AIX related effort ; I put it again into our internal build/test queue. > > With the latest commit the build again fails on AIX with this error > > /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] > result = fstatvfs(fd, &file_stat); > ^~~~~~~~~~ > /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here > extern int fstatvfs(int, struct statvfs *); > Well, well... The code at least looks cleaner without these AIX defines, so I really hope that this is the end of the AIX saga, at the `n+1`th time. @MBaesken Can you rerun AIX testing with the latest commit? Latest commit looks still good on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933652124 From sspitsyn at openjdk.org Thu Feb 8 09:54:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Feb 2024 09:54:56 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: <7qxBGiPcbwyhFMbHpQOmRsgmg1qJFfL875Yyax6OZtM=.962c9c81-b613-49dd-a6c3-92efb256f0e4@github.com> On Wed, 7 Feb 2024 21:56:01 GMT, Daniel D. Daugherty wrote: >> Serguei Spitsyn 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 >> - review: thread in notify waiter list can't be BLOCKED >> - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1489: > >> 1487: nWait = mon->waiters(); // # of threads in Object.wait() >> 1488: ret.waiter_count = nWant; >> 1489: ret.notify_waiter_count = nWait; > > Please note that the comment on L1487 is accurate. The `waiters` count is > incremented just before the thread that has called `wait()` drops the monitor > and that increased count remains in effect until after the thread has reentered > the monitor after being notified or the wait timeout has expired. > > The `contentions` count is not incremented in the re-entry path so a thread > that is in `wait()` that has been notified or the wait timeout has expired is not > counted as a contending thread. > > So if we really want the `waiter_count` field to include threads that have been > notified or the wait timeout has expired, then we have to add some logic to > carefully increment the `contentions` count. > > This old logic: > ``` ret.waiter_count = nWant + nWait;``` > over counts because it also includes threads in `wait()` that have not yet > been notified and the wait timeout has not expired. However, including > `nWait` is correct for the situation when all of the waiting threads have > been notified or their wait timeouts have expired. > > This also means that `nWait` and the `ret.notify_waiter_count` value are > over counting waiters because that value will include threads that (have > been notified or the wait timeout has expired) AND have not reentered > the monitor. I _think_ we're saying that is NOT what we want. However, > I _think_ that the `nWait` value is fixed below when we're gathering up > the list of waiters. Thank you for reviewing this, Dan! > The contentions count is not incremented in the re-entry path so a thread that is in wait() that has been notified or the wait timeout has expired is not counted as a contending thread. Right. I've discovered this after reading your first comment above this comment. :) I agree with the whole comment. I understand this over counting now. It is a good catch! Will work on fixing this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482696229 From sspitsyn at openjdk.org Thu Feb 8 09:58:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Feb 2024 09:58:56 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 22:43:36 GMT, Daniel D. Daugherty wrote: >> Serguei Spitsyn 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 >> - review: thread in notify waiter list can't be BLOCKED >> - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp line 161: > >> 159: >> 160: if (inf.notify_waiter_count != notifyWaiterCount) { >> 161: printf("(%d) waiter_count expected: %d, actually: %d\n", > > nit typo: s/waiter_count/notify_waiter_count/ Nice catch, thanks! > test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/objmonusage003.cpp line 150: > >> 148: >> 149: if (inf.notify_waiter_count != notifyWaiterCount) { >> 150: printf("(%d) waiter_count expected: %d, actually: %d\n", > > nit typo: s/waiter_count/notify_waiter_count/ Nice catch, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482702600 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482702844 From sroy at openjdk.org Thu Feb 8 09:59:11 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 8 Feb 2024 09:59:11 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v16] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Free the buffer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/14e0ed39..0503ed8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=14-15 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From jkern at openjdk.org Thu Feb 8 10:03:59 2024 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 8 Feb 2024 10:03:59 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v16] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Thu, 8 Feb 2024 09:59:11 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Free the buffer src/hotspot/os/aix/os_aix.cpp line 1114: > 1112: > 1113: log_info(os)("attempting shared library load of %s", filename); > 1114: printf("Loading the filename %s\n",filename); Is this just accidentally remaining debug code or do you want to protocol each dlopen on stdout? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1482709076 From sspitsyn at openjdk.org Thu Feb 8 10:08:03 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Feb 2024 10:08:03 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 22:49:31 GMT, Daniel D. Daugherty wrote: >> Serguei Spitsyn 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 >> - review: thread in notify waiter list can't be BLOCKED >> - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp line 95: > >> 93: >> 94: JNIEXPORT void JNICALL >> 95: Java_nsk_jvmti_GetObjectMonitorUsage_objmonusage001_check(JNIEnv *env, > > I would have expected a modification to an objmonusage001.java file to update > the parameters to that test's `check()` function. The parameters of the `check()` method are named short. It is why I decided to skip this update. Now, I decided to rename parameters to keep them consistent with the other test `objmonusage003`. So, it has been fixed now, thank you for the suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482714109 From sroy at openjdk.org Thu Feb 8 10:23:17 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 8 Feb 2024 10:23:17 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v17] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision: - spaces and comma - debug lines - remove debug lines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/0503ed8f..f4b85357 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=15-16 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From sroy at openjdk.org Thu Feb 8 10:25:58 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 8 Feb 2024 10:25:58 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Tue, 6 Feb 2024 10:26:36 GMT, Joachim Kern wrote: > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden? Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933769585 From sroy at openjdk.org Thu Feb 8 10:28:59 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 8 Feb 2024 10:28:59 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 5 Feb 2024 09:01:38 GMT, Martin Doerr wrote: > The trailing whitespace errors must get fixed (integration blocker). I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933774774 From jkern at openjdk.org Thu Feb 8 10:32:58 2024 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 8 Feb 2024 10:32:58 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Thu, 8 Feb 2024 10:22:53 GMT, Suchismith Roy wrote: > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden? > > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933782205 From sspitsyn at openjdk.org Thu Feb 8 10:36:57 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Feb 2024 10:36:57 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 22:37:55 GMT, Daniel D. Daugherty wrote: >> Serguei Spitsyn 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 >> - review: thread in notify waiter list can't be BLOCKED >> - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1521: > >> 1519: // we have contending and/or waiting threads >> 1520: if (nWant > 0) { >> 1521: // we have contending threads > > This block includes this logic: > > // get_pending_threads returns only java thread so we do not need to > // check for non java threads. > GrowableArray* wantList = Threads::get_pending_threads(tlh.list(), nWant, (address)mon); > if (wantList->length() < nWant) { > // robustness: the pending list has gotten smaller > nWant = wantList->length(); > } > > `Threads::get_pending_threads()` only returns threads where the > `current_pending_monitor` field is set for the specific monitor. That > happens only on contended enter and does not happen on contended > re-enter so this logic will already strip out any threads in `wait()` that > have not been notified and have not had their wait timers expire. > It will also strip out any waiters that have been notified or had > their wait timeouts expire. > > This means even if we fix the reenter code to increment the contentions > field, this logic will reduce that `nWant` value. Of course, the way around > that is to also update the reenter code to properly set the `current_pending_monitor` > field and then the reentering threads won't be filtered out... Yes, I've figured this out now. Thank you for pointing to it. It feels, the counts can be calculated correctly without touching the implementation of `current_pending_monitor()`, `current_waiting_monitor()`, `_contensions` and `_waiters`. At least, I'll try to fix it locally in the `JvmtiEnvBase::get_object_monitor_usage()`. Please, let me know what do you prefer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482749279 From kevinw at openjdk.org Thu Feb 8 10:39:53 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Feb 2024 10:39:53 GMT Subject: RFR: 8316460: 4 javax/management tests ignore VM flags In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 05:38:32 GMT, Leonid Mesnik wrote: > The tests > javax/management/ImplementationVersion/ImplVersionTest.java > javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java > javax/management/remote/mandatory/version/ImplVersionTest.java > javax/management/security/HashedPasswordFileTest.java > were updated to use > ProcessTools.createTestJavaProcessBuilder(...) > > Tested by running tests with different jvm flags and tier1. Looks good. I think you're saying this creates no obvious new failures. 8-) Is there a bug on why we are problemlisting those two ImplVersion tests? They are SecurityManager related, and I see your failures with an access denied problem, but I see them passing also, and some different failures in the history. I'm not sure these tests have a great value, but we want to track the problemlisting I think. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17764#pullrequestreview-1869795183 From sroy at openjdk.org Thu Feb 8 10:41:01 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 8 Feb 2024 10:41:01 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Thu, 8 Feb 2024 10:30:43 GMT, Joachim Kern wrote: > > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden? > > > > > > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) > > Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case Do we have a case where a .so files has braces mentioning the archive members ? I think not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933795230 From jkern at openjdk.org Thu Feb 8 10:48:58 2024 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 8 Feb 2024 10:48:58 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: <3SJSb4UmmbrEz3Lwb8onh4qcDnLJ-XER8Sk9jnjqV3I=.63c5aa4e-5f15-4249-abc4-271a50b537d4@github.com> On Thu, 8 Feb 2024 10:38:37 GMT, Suchismith Roy wrote: > > > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden? > > > > > > > > > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) > > > > > > Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case > > Do we have a case where a .so files has braces mentioning the archive members ? I think not. That's why I am asking. If not this is an academical concern. But it should be mentioned in a comment, that this is not expected to work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933808741 From sroy at openjdk.org Thu Feb 8 11:04:00 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 8 Feb 2024 11:04:00 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: <3SJSb4UmmbrEz3Lwb8onh4qcDnLJ-XER8Sk9jnjqV3I=.63c5aa4e-5f15-4249-abc4-271a50b537d4@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <3SJSb4UmmbrEz3Lwb8onh4qcDnLJ-XER8Sk9jnjqV3I=.63c5aa4e-5f15-4249-abc4-271a50b537d4@github.com> Message-ID: On Thu, 8 Feb 2024 10:46:37 GMT, Joachim Kern wrote: > > > > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden? > > > > > > > > > > > > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) > > > > > > > > > Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case > > > > > > Do we have a case where a .so files has braces mentioning the archive members ? I think not. > > That's why I am asking. If not this is an academical concern. But it should be mentioned in a comment, that this is not expected to work. Yes, but i was also asking if at all there is a case ,which i am not aware of. Sure i will mention it in comments. But there is one case that keep me thinking, is that ..will a particular .so file have an .a file with same name, but also referred to a member ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933833986 From ihse at openjdk.org Thu Feb 8 13:42:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Feb 2024 13:42:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Once more, remove AIX dirent64 et al defines > > And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. > The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes. @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of *all* AIX 64-bit redefines, and then I'll (probably) do it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934144258 From mgronlun at openjdk.org Thu Feb 8 14:16:23 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 8 Feb 2024 14:16:23 GMT Subject: RFR: 8323883: JFR AssertionError: Missing object ID 15101 Message-ID: Greetings, The following adjustments fix the intermittent issues with incomplete tag sets for a chunk. The situations are pretty subtle: 1. A situation can occur where an event is emitted during the event instrumentation callback as part of JVMTI Retransform (ErrorThrownEvent). A stack trace is captured that marks, or "tags", the existing method(s) of the klass (i.e. when the scratch class is instrumented). But after the instrumentation call returns, the set of methods of the klass is exchanged from the "old" methods (now marked) , to the new set of methods (from the scratch class, not marked). This means the mark/tag is lost for a method. Therefore, method tags must be transferred when exchanging methods during JVMTI redefine / retransform. 2. OldObjectSample events are emitted at the end of a recording. As part of writing the events, several checkpoint events are also created and enqueued. But these checkpoints are incomplete standalone because they need to be complemented with a typeset checkpoint, which happens just after, as part of the rotation. But flush() can occur concurrently with OldObjectSample emit, and can, therefore, serialize these checkpoints to a segment before the complementary typeset checkpoint has been created. There needs to be mutual exclusion between OldObjectSample emit() and flush(), now provided by the JfrRotationLock. 3. The set of artifacts captured during class unloading is incomplete because it respects already serialized artifacts. However, because class unloading typesets are linked to OldObjectSamples and DeprecationInvocation events, which survive chunk boundaries, those unloading typesets can be serialized in later chunks. If the unloading set is incomplete (not transitive), there will be missing constants. Hence, class unloading typesets require serialization of the entire transitive set of unloading artefacts, even if they have already been serialized to the current chunk. As part of fixing these issues, the disabled assert is also reactivated. Testing: jdk_jfr, stress testing, tier 1-6 Thanks Markus ------------- Commit messages: - revert jfrTraceIdMacros.hpp - revert jfrTraceId.cpp - cleared bits not needed on initialization - 8323883 Changes: https://git.openjdk.org/jdk/pull/17771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17771&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323883 Stats: 167 lines in 15 files changed: 81 ins; 48 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/17771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17771/head:pull/17771 PR: https://git.openjdk.org/jdk/pull/17771 From jkern at openjdk.org Thu Feb 8 14:25:59 2024 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 8 Feb 2024 14:25:59 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <3SJSb4UmmbrEz3Lwb8onh4qcDnLJ-XER8Sk9jnjqV3I=.63c5aa4e-5f15-4249-abc4-271a50b537d4@github.com> Message-ID: <5C9t4TRNHNH5DOj7GP3_Lmg6FVFXT0OqZwf5LHRMf4M=.3f5766da-6ba2-486e-8330-855b63300b4e@github.com> On Thu, 8 Feb 2024 11:01:25 GMT, Suchismith Roy wrote: > > > > > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden? > > > > > > > > > > > > > > > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) > > > > > > > > > > > > Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case > > > > > > > > > Do we have a case where a .so files has braces mentioning the archive members ? I think not. > > > > > > That's why I am asking. If not this is an academical concern. But it should be mentioned in a comment, that this is not expected to work. > > Yes, but i was also asking if at all there is a case ,which i am not aware of. Sure i will mention it in comments. But there is one case that keep me thinking, is that ..will a particular .so file have an .a file with same name, but also referred to a member ? No, there is no case I'm aware of. Just theoretical thinking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1934227854 From kevinw at openjdk.org Thu Feb 8 14:35:05 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Feb 2024 14:35:05 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl wrote: > 8307977: jcmd and jstack broken for target processes running with elevated capabilities Thanks, yes that's what I was thinking about. I tested and think it's a good update to this change. I tested setting sudo setcap 'cap_net_bind_service=+ep' build/linux-x64/images/jdk/bin/java ..and then with jcmd I do see the EACCES on e.g. "/proc/27979/root/tmp/.java_pid27979" I see the failure to attach, and I see it fixed by this change. I also see the EACCESS on the .attach_pid file in cwd, e.g. in strace: 26682 open("/proc/26593/cwd/.attach_pid26593", O_RDWR|O_CREAT|O_EXCL, 0666 ... 26682 <... open resumed>) = -1 EACCES (Permission denied) We catch this and retry in /tmp. But exactly as in your response, we can predict that and if not in a namespace, go straight to /tmp. I tested what you have there and it works well. Also tested that a new jcmd attaching to an older JDK, that still works. One other thing - JDK-8226919 looks like the original bug for this, logged a few years back, so if this fixes both, the record should show that it fixes that one, and JDK-8307977 should be closed as a duplicate. I/somebody can take care of that JBS admin. But if this PR could be associated with only JDK-8226919 that would be simple. Thanks! 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1934246614 From mdoerr at openjdk.org Thu Feb 8 14:42:07 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 8 Feb 2024 14:42:07 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: <1kzsCJOR4U-lc77vCBrS_Oa4YCoBv5a7Zz8gKDHDuXg=.9471c3b3-cea7-415b-aa18-79aa76f508d1@github.com> On Thu, 8 Feb 2024 10:26:05 GMT, Suchismith Roy wrote: > > The trailing whitespace errors must get fixed (integration blocker). > > I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ? Strange. I don't see any whitespace problem, either. Maybe it's possible to rerun jcheck (GitHub Actions). Otherwise, you may need to create a new PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1934260353 From jkern at openjdk.org Thu Feb 8 14:50:08 2024 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 8 Feb 2024 14:50:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Once more, remove AIX dirent64 et al defines > > And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. > The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes. > @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it. Same as `statvfs`. Only the file system ID field is smaller. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934275624 From dcubed at openjdk.org Thu Feb 8 15:22:04 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Feb 2024 15:22:04 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl wrote: > 8307977: jcmd and jstack broken for target processes running with elevated capabilities Will this result in files being left in /tmp that are not cleaned up during test runs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1934350422 From dcubed at openjdk.org Thu Feb 8 15:32:03 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Feb 2024 15:32:03 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:34:14 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1521: >> >>> 1519: // we have contending and/or waiting threads >>> 1520: if (nWant > 0) { >>> 1521: // we have contending threads >> >> This block includes this logic: >> >> // get_pending_threads returns only java thread so we do not need to >> // check for non java threads. >> GrowableArray* wantList = Threads::get_pending_threads(tlh.list(), nWant, (address)mon); >> if (wantList->length() < nWant) { >> // robustness: the pending list has gotten smaller >> nWant = wantList->length(); >> } >> >> `Threads::get_pending_threads()` only returns threads where the >> `current_pending_monitor` field is set for the specific monitor. That >> happens only on contended enter and does not happen on contended >> re-enter so this logic will already strip out any threads in `wait()` that >> have not been notified and have not had their wait timers expire. >> It will also strip out any waiters that have been notified or had >> their wait timeouts expire. >> >> This means even if we fix the reenter code to increment the contentions >> field, this logic will reduce that `nWant` value. Of course, the way around >> that is to also update the reenter code to properly set the `current_pending_monitor` >> field and then the reentering threads won't be filtered out... > > Yes, I've figured this out now. Thank you for pointing to it. > It feels, the counts can be calculated correctly without touching the implementation of `current_pending_monitor()`, `current_waiting_monitor()`, `_contensions` and `_waiters`. > At least, I'll try to fix it locally in the `JvmtiEnvBase::get_object_monitor_usage()`. > Please, let me know what do you prefer. I don't have a preference (yet). Like what David suggested, I think we need to determine the list of thread and monitor interaction scenarios that want to exercise with this API. Once we're happy that those scenarios represent the complete list of possible combinations we should double check that against the API spec to make sure that those scenarios cover the API spec. Finally, we need to make sure that we have a test that covers all those scenarios. It has been a long, long time since I've looked at those NSK tests... :-( ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1483168890 From lmesnik at openjdk.org Thu Feb 8 16:00:07 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 Feb 2024 16:00:07 GMT Subject: RFR: 8316460: 4 javax/management tests ignore VM flags In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:36:52 GMT, Kevin Walls wrote: > Is there a bug on why we are problemlisting those two ImplVersion tests? They are permanently excluded from execution with the virtual thread test factory. The virtual threads are not compatible with the secutiry manager. It is not going to be fixed and bug is not needed here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17764#issuecomment-1934429400 From kevinw at openjdk.org Thu Feb 8 16:50:03 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Feb 2024 16:50:03 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: <3zTsgMeaNMs-uPAfKDPYQi6iVlVsn9DjhT5XykkLXZ0=.23de2a4a-96f9-48ec-8d80-8386f3475787@github.com> On Thu, 8 Feb 2024 15:19:23 GMT, Daniel D. Daugherty wrote: > Will this result in files being left in /tmp that are not cleaned up during test runs? It shouldn't... We do cleanup, VirtualMachineImpl creates the attach file and deletes it in a finally block. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1934528586 From dcubed at openjdk.org Thu Feb 8 16:58:06 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Feb 2024 16:58:06 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: <4lV5dd0Kddf7r2PFkCHxJqrYpo5f2K1psf9qUzTZX5k=.d6447ae4-fabd-47bb-8ca5-d47cd1681c6d@github.com> On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl wrote: > 8307977: jcmd and jstack broken for target processes running with elevated capabilities Cool. Thanks for the confirmation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1934542288 From ihse at openjdk.org Thu Feb 8 18:20:16 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Feb 2024 18:20:16 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Once more, remove AIX dirent64 et al defines And the smaller file system ID is not a problem, I guess? Do you want me to remove the redefines? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934691860 From lmesnik at openjdk.org Thu Feb 8 23:31:09 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 Feb 2024 23:31:09 GMT Subject: RFR: 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only Message-ID: There are several .sh tests which use ${TESTVMOPTS} only. Updated them to use ${TESTJAVAOPTS} also. Tested by running them with different options and tier1. ------------- Commit messages: - 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only Changes: https://git.openjdk.org/jdk/pull/17780/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17780&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319578 Stats: 35 lines in 14 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/17780.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17780/head:pull/17780 PR: https://git.openjdk.org/jdk/pull/17780 From lmesnik at openjdk.org Thu Feb 8 23:35:26 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 Feb 2024 23:35:26 GMT Subject: RFR: 8316451: 6 java/lang/instrument/PremainClass tests ignore VM flags Message-ID: Tests updated to use jtreg vm flags. Tested by running tests with different flags and tier1. ------------- Commit messages: - 8316451 Changes: https://git.openjdk.org/jdk/pull/17781/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17781&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316451 Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17781/head:pull/17781 PR: https://git.openjdk.org/jdk/pull/17781 From lmesnik at openjdk.org Fri Feb 9 02:37:02 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Feb 2024 02:37:02 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 20:53:53 GMT, Alex Menkov wrote: > The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). > The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. > > testing: > - sanity tier1; > - all RedefineClasses/RetransformClasses 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 src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1828: > 1826: // ensure merged constant pool size does not overflow u2 > 1827: if (merge_cp_length > 0xFFFF) { > 1828: return JVMTI_ERROR_INTERNAL; Doesn't it make a sense to add some logging there so user could easier understand the problem? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17759#discussion_r1483803900 From coleenp at openjdk.org Fri Feb 9 03:31:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Feb 2024 03:31:04 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 20:53:53 GMT, Alex Menkov wrote: > The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). > The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. > > testing: > - sanity tier1; > - all RedefineClasses/RetransformClasses 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 Thank you for fixing this. Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17759#pullrequestreview-1871604187 From coleenp at openjdk.org Fri Feb 9 03:31:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Feb 2024 03:31:04 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow In-Reply-To: References: Message-ID: <8jAkfYsTL8RV4jg3_dXfQZaTp4BP_wx9scBRt1nWl6A=.85bc28e0-6c17-4964-91d0-d25d6cee4cca@github.com> On Fri, 9 Feb 2024 02:34:26 GMT, Leonid Mesnik wrote: >> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). >> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. >> >> testing: >> - sanity tier1; >> - all RedefineClasses/RetransformClasses 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 > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1828: > >> 1826: // ensure merged constant pool size does not overflow u2 >> 1827: if (merge_cp_length > 0xFFFF) { >> 1828: return JVMTI_ERROR_INTERNAL; > > Doesn't it make a sense to add some logging there so user could easier understand the problem? Seems like a good idea, you can use log_warning(redefine, class, constantpool)("...") ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17759#discussion_r1483825615 From cjplummer at openjdk.org Fri Feb 9 03:43:54 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Feb 2024 03:43:54 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 20:53:53 GMT, Alex Menkov wrote: > The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). > The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. > > testing: > - sanity tier1; > - all RedefineClasses/RetransformClasses 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 It looks like we don't have a reproducer for this issue. Please add the appropriate noreg label. ------------- PR Review: https://git.openjdk.org/jdk/pull/17759#pullrequestreview-1871610809 From duke at openjdk.org Fri Feb 9 05:31:17 2024 From: duke at openjdk.org (Yifeng Jin) Date: Fri, 9 Feb 2024 05:31:17 GMT Subject: RFR: 8325464: GCCause.java out of sync with gcCause.hpp [v2] In-Reply-To: References: Message-ID: > These two files (`GCCause.java` and `gcCause.hpp`) should be in sync by design, see comments in these two files. However, some recent changes (e.g. [JDK-8240239](https://bugs.openjdk.org/browse/JDK-8240239)) to `gcCause.hpp` were not simultaneously reflected in `GCCause.java`. This patch updates `GCCause.java` to keep sync with latest `gcCause.hpp`. Yifeng Jin has updated the pull request incrementally with one additional commit since the last revision: swap zgc and shenandoah block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17766/files - new: https://git.openjdk.org/jdk/pull/17766/files/36407800..29224950 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17766&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17766&range=00-01 Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17766/head:pull/17766 PR: https://git.openjdk.org/jdk/pull/17766 From duke at openjdk.org Fri Feb 9 05:39:53 2024 From: duke at openjdk.org (Yifeng Jin) Date: Fri, 9 Feb 2024 05:39:53 GMT Subject: RFR: 8325464: GCCause.java out of sync with gcCause.hpp [v2] In-Reply-To: References: Message-ID: <3n_kp3buoStiusT5UltEvPO5XnbRILfdI6wVWuaeFl0=.25a008e1-c8e6-4a0b-9e85-de68f235e3e4@github.com> On Thu, 8 Feb 2024 08:39:44 GMT, Stefan Karlsson wrote: >> Yifeng Jin has updated the pull request incrementally with one additional commit since the last revision: >> >> swap zgc and shenandoah block > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java line 65: > >> 63: _z_allocation_stall ("Allocation Stall"), >> 64: _z_proactive ("Proactive"), >> 65: _z_high_usage ("High Usage"), > > gcCause.hpp has the Shenandoah and ZGC blocks swapped. Could you fix it in this change as well? OK, I have swapped the Shenandoah and ZGC blocks here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17766#discussion_r1483882863 From stefank at openjdk.org Fri Feb 9 07:34:53 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 Feb 2024 07:34:53 GMT Subject: RFR: 8325464: GCCause.java out of sync with gcCause.hpp [v2] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 05:31:17 GMT, Yifeng Jin wrote: >> These two files (`GCCause.java` and `gcCause.hpp`) should be in sync by design, see comments in these two files. However, some recent changes (e.g. [JDK-8240239](https://bugs.openjdk.org/browse/JDK-8240239)) to `gcCause.hpp` were not simultaneously reflected in `GCCause.java`. This patch updates `GCCause.java` to keep sync with latest `gcCause.hpp`. > > Yifeng Jin has updated the pull request incrementally with one additional commit since the last revision: > > swap zgc and shenandoah block Looks good. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17766#pullrequestreview-1871801118 From tschatzl at openjdk.org Fri Feb 9 08:27:53 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 9 Feb 2024 08:27:53 GMT Subject: RFR: 8325464: GCCause.java out of sync with gcCause.hpp [v2] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 05:31:17 GMT, Yifeng Jin wrote: >> These two files (`GCCause.java` and `gcCause.hpp`) should be in sync by design, see comments in these two files. However, some recent changes (e.g. [JDK-8240239](https://bugs.openjdk.org/browse/JDK-8240239)) to `gcCause.hpp` were not simultaneously reflected in `GCCause.java`. This patch updates `GCCause.java` to keep sync with latest `gcCause.hpp`. > > Yifeng Jin has updated the pull request incrementally with one additional commit since the last revision: > > swap zgc and shenandoah block Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17766#pullrequestreview-1871871145 From kevinw at openjdk.org Fri Feb 9 09:35:05 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Feb 2024 09:35:05 GMT Subject: RFR: 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 23:26:30 GMT, Leonid Mesnik wrote: > There are several .sh tests which use ${TESTVMOPTS} only. Updated them to use ${TESTJAVAOPTS} also. > Tested by running them with different options and tier1. Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17780#pullrequestreview-1871979946 From alanb at openjdk.org Fri Feb 9 11:41:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Feb 2024 11:41:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Once more, remove AIX dirent64 et al defines I can't comment on AIX but the changes look okay overall. I assume you'll bump the copyright header date on all the updated files before integrating. src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 257: > 255: static int fstatat_wrapper(int dfd, const char *path, > 256: struct stat *statbuf, int flag) > 257: { Minor nit - you can probably fix the align after the edit or collapse it into one line. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1872182776 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1484203284 From ihse at openjdk.org Fri Feb 9 13:41:39 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 Feb 2024 13:41:39 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files Message-ID: This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. With Skara jcheck, it is possible to increase the coverage of the whitespace checks. However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. ------------- Commit messages: - 8325558: Add jcheck whitespace checking for properties files Changes: https://git.openjdk.org/jdk/pull/17789/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17789&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325558 Stats: 761 lines in 95 files changed: 0 ins; 5 del; 756 mod Patch: https://git.openjdk.org/jdk/pull/17789.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17789/head:pull/17789 PR: https://git.openjdk.org/jdk/pull/17789 From ihse at openjdk.org Fri Feb 9 13:41:39 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 Feb 2024 13:41:39 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. > > With Skara jcheck, it is possible to increase the coverage of the whitespace checks. > > However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. I'll add some specific comments/reasoning to individual files, where I think a remark might be needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935947566 From ihse at openjdk.org Fri Feb 9 13:55:09 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 Feb 2024 13:55:09 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. > > With Skara jcheck, it is possible to increase the coverage of the whitespace checks. > > However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. src/java.base/unix/classes/sun/net/www/content-types.properties line 1: > 1: #sun.net.www MIME content-types table I have converted all leading tabs to 8 spaces. src/java.base/windows/classes/sun/net/www/content-types.properties line 1: > 1: #sun.net.www MIME content-types table I have converted all leading tabs to 8 spaces. src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties line 11: > 9: ImageUtil0=The supplied Raster does not represent a binary data set. > 10: ImageUtil1=The provided sample model is null. > 11: ImageUtil2=The provided image cannot be encoded using: While it seems like this could have been significant, the code that uses it looks like this: throw new IIOException(I18N.getString("ImageUtil2")+" "+ writer.getClass().getName()); so it will end up with a double space right now. src/java.scripting/share/classes/com/sun/tools/script/shell/messages.properties line 1: > 1: # I have converted all leading tabs to 8 spaces. src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73: > 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size > 72: cachedrowsetimpl.startpos = Start position cannot be negative > 73: cachedrowsetimpl.nextpage = Populate data before calling This sounded like it could potentially be followed by a name, but this is not the case. src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128: > 126: crswriter.params1 = Value of params1 : {0} > 127: crswriter.params2 = Value of params2 : {0} > 128: crswriter.conflictsno = conflicts while synchronizing This sounded like it could potentially be followed by a string, but this is not the case. src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 1: > 1: # The changes in this and the following files are just to align the file with the English master copy. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24: > 22: > 23: BadMessageKey = The error message corresponding to the message key can not be found. > 24: FormatFailed = An internal error occurred while formatting the following message:\n At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties line 1: > 1: # The changes in this and the following files are just to align the file with the English master copy. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties line 1: > 1: # The changes in this and the following files are just to align the file with the English master copy. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties line 20: > 18: # Messages for message reporting > 19: BadMessageKey = The error message corresponding to the message key can not be found. > 20: FormatFailed = An internal error occurred while formatting the following message:\n At first glance, it might look like something should follow the :, but note that there is a \n so if anything this will only make the next line improperly indented. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties line 1: > 1: # The changes in this and the following files are just to align the file with the English master copy. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 27: > 25: > 26: BadMessageKey = The error message corresponding to the message key can not be found. > 27: FormatFailed = An internal error occurred while formatting the following message:\n Same here with `:\n`... src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24: > 22: # Messages for message reporting > 23: BadMessageKey = The error message corresponding to the message key can not be found. > 24: FormatFailed = An internal error occurred while formatting the following message:\n Same here with `:\n`... src/jdk.compiler/share/classes/sun/tools/serialver/resources/serialver.properties line 1: > 1: # I have converted all leading tabs to 8 spaces. src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 49: > 47: 'u' flag requires manifest, 'e' flag or input files to be specified! > 48: error.bad.eflag=\ > 49: 'e' flag and manifest with the 'Main-Class' attribute cannot be specified \n\ Here were two lines that used tab instead of space; I converted them to 8 spaces. test/jaxp/javax/xml/jaxp/unittest/common/config/files/catalog2.properties line 4: > 2: # XML Library (java.xml) Configuration File > 3: # > 4: # This file is in java.util.Properties format and typically located in the conf These spaces at the end of comment lines has crept in since I cleaned all such out in [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047). It's a good example of why we need the jcheck verification to keep this from regressing once more. test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties line 12: > 10: > 11: TableDemo.noDataStatusLabel=No data loaded > 12: TableDemo.loadingStatusLabel=Loading data:\u0020 According to https://github.com/openjdk/jdk/pull/11488/files#r1038605801 the latter two are actually needed as spaces, and the first might be; so keeping it as well seems to be the safe choice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326435 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326568 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327614 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327859 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329632 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329770 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484330650 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332081 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332649 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334629 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334259 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335061 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335669 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484337306 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484338418 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484339114 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484341847 PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484345466 From dfuchs at openjdk.org Fri Feb 9 14:10:57 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 9 Feb 2024 14:10:57 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. > > With Skara jcheck, it is possible to increase the coverage of the whitespace checks. > > However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. changes to sun/net content-types.properties look OK ------------- PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935996382 From erikj at openjdk.org Fri Feb 9 14:56:57 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Feb 2024 14:56:57 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:42:02 GMT, Magnus Ihse Bursie wrote: >> This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. >> >> With Skara jcheck, it is possible to increase the coverage of the whitespace checks. >> >> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. > > src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24: > >> 22: >> 23: BadMessageKey = The error message corresponding to the message key can not be found. >> 24: FormatFailed = An internal error occurred while formatting the following message:\n > > At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented. That could have been intentional though. Not sure if it was a good idea, but indenting something is a way of making something stand out as a quote. But looking at every use site, there is an extra space added anyway, so this seems fine. If we wanted to preserve the exact same behavior, all use sites should be updated to add 3 spaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484416962 From egahlin at openjdk.org Fri Feb 9 15:54:03 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 9 Feb 2024 15:54:03 GMT Subject: RFR: 8323883: JFR AssertionError: Missing object ID 15101 In-Reply-To: References: Message-ID: <1tI2HvKcvzBT4aI5B-aebO6o2_BWkOKeHoNNwcRug6E=.21d5452a-c5f1-4afc-afc2-c589d2c444f0@github.com> On Thu, 8 Feb 2024 13:46:40 GMT, Markus Gr?nlund wrote: > Greetings, > > The following adjustments fix the intermittent issues with incomplete tag sets for a chunk. The situations are pretty subtle: > > 1. A situation can occur where an event is emitted during the event instrumentation callback as part of JVMTI Retransform (ErrorThrownEvent). A stack trace is captured that marks, or "tags", the existing method(s) of the klass (i.e. when the scratch class is instrumented). But after the instrumentation call returns, the set of methods of the klass is exchanged from the "old" methods (now marked) , to the new set of methods (from the scratch class, not marked). This means the mark/tag is lost for a method. Therefore, method tags must be transferred when exchanging methods during JVMTI redefine / retransform. > 2. OldObjectSample events are emitted at the end of a recording. As part of writing the events, several checkpoint events are also created and enqueued. But these checkpoints are incomplete standalone because they need to be complemented with a typeset checkpoint, which happens just after, as part of the rotation. But flush() can occur concurrently with OldObjectSample emit, and can, therefore, serialize these checkpoints to a segment before the complementary typeset checkpoint has been created. There needs to be mutual exclusion between OldObjectSample emit() and flush(), now provided by the JfrRotationLock. > 3. The set of artefacts captured during class unloading is incomplete because it respects already serialized artefacts. However, because class unloading typesets are linked to OldObjectSamples and DeprecatedInvocation events, which survive chunk boundaries, these unloading typesets can be serialized in later chunks. If the unloading set is incomplete (not transitive), there will be missing constants. Hence, class unloading typesets require serialization of the entire transitive set of unloading artefacts, even if they have already been serialized to the current chunk. > > As part of fixing these issues, the disabled assert is also reactivated. > > Testing: jdk_jfr, stress testing, tier 1-6 > > Thanks > Markus Nice work! Let's hope this will be the last "missing object ID" bug to make it into main line. ------------- Marked as reviewed by egahlin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17771#pullrequestreview-1872708791 From cjplummer at openjdk.org Fri Feb 9 17:28:04 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Feb 2024 17:28:04 GMT Subject: RFR: 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 23:26:30 GMT, Leonid Mesnik wrote: > There are several .sh tests which use ${TESTVMOPTS} only. Updated them to use ${TESTJAVAOPTS} also. > Tested by running them with different options and tier1. The changes look fine. What testing have you done? Would be good to test with options like -Xcomp and different GCs. which are probably the options most likely to impact these tests. Maybe JFR also. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17780#pullrequestreview-1872878082 From kevinw at openjdk.org Fri Feb 9 18:09:00 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Feb 2024 18:09:00 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl wrote: > 8307977: jcmd and jstack broken for target processes running with elevated capabilities Marked as reviewed by kevinw (Reviewer). Hi, looking at it again: Getting a target's current directory, you have to use /proc/PID/cwd, or you can fall back to using tmpdir. The attach listener uses cwd and then tmpdir, so they will meet either way. When getting the target's current directory, /proc/PID/cwd will fail for the evelated processes, but will work for others (where permissions allow). So although I suggested the additional change, it can't be that much more efficient as it just makes the native attach listener try the second location... So that was all very interesting, but let me just approve what we have here already. No need to proceed with the additional code you had in the comment response above. 8-) ------------- PR Review: https://git.openjdk.org/jdk/pull/17628#pullrequestreview-1872947652 PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1936379964 From naoto at openjdk.org Fri Feb 9 18:12:06 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 Feb 2024 18:12:06 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. > > With Skara jcheck, it is possible to increase the coverage of the whitespace checks. > > However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces. ------------- PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1872951198 From duke at openjdk.org Fri Feb 9 18:21:04 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Fri, 9 Feb 2024 18:21:04 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: References: Message-ID: <7vessvLp3h1VbXvYrU855MWBnK6MB0XLsQokmm6ynM4=.e97f68cc-efd7-4c83-a36f-4031d784e5b1@github.com> On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl wrote: > 8307977: jcmd and jstack broken for target processes running with elevated capabilities Alright, sounds good to me. :) Thanks again for taking a look! > One other thing - JDK-8226919 looks like the original bug for this, logged a few years back, so if this fixes both, the record should show that it fixes that one, and JDK-8307977 should be closed as a duplicate. I/somebody can take care of that JBS admin. But if this PR could be associated with only JDK-8226919 that would be simple. I'll still fix this. So, I should change the PR title to match JDK-8226919, and issue an `/issue remove` command for JDK-8307977, is that correct? Once that is done, I would kindly ask for someone sponsoring this change as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1936398081 From kevinw at openjdk.org Fri Feb 9 18:25:03 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Feb 2024 18:25:03 GMT Subject: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities In-Reply-To: <7vessvLp3h1VbXvYrU855MWBnK6MB0XLsQokmm6ynM4=.e97f68cc-efd7-4c83-a36f-4031d784e5b1@github.com> References: <7vessvLp3h1VbXvYrU855MWBnK6MB0XLsQokmm6ynM4=.e97f68cc-efd7-4c83-a36f-4031d784e5b1@github.com> Message-ID: <2ofyu9f8afgL3MxQ4YeMk9Bk6p-a55rMOXlHq3Q41ZY=.d6d2606a-3a95-479e-8f0b-7ca87cf83575@github.com> On Fri, 9 Feb 2024 18:17:58 GMT, Sebastian L?vdahl wrote: > I'll still fix this. So, I should change the PR title to match JDK-8226919, and issue an `/issue remove` command for JDK-8307977, is that correct? Yes exactly, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1936404118 From duke at openjdk.org Fri Feb 9 18:35:07 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Fri, 9 Feb 2024 18:35:07 GMT Subject: Integrated: 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl wrote: > 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root This pull request has now been integrated. Changeset: ac4607ed Author: Sebastian L?vdahl Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/ac4607ed81eb75f43e7d1062e38506972738d086 Stats: 36 lines in 1 file changed: 21 ins; 11 del; 4 mod 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root Reviewed-by: sgehwolf, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/17628 From lmesnik at openjdk.org Fri Feb 9 18:43:08 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Feb 2024 18:43:08 GMT Subject: Integrated: 8316460: 4 javax/management tests ignore VM flags In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 05:38:32 GMT, Leonid Mesnik wrote: > The tests > javax/management/ImplementationVersion/ImplVersionTest.java > javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java > javax/management/remote/mandatory/version/ImplVersionTest.java > javax/management/security/HashedPasswordFileTest.java > were updated to use > ProcessTools.createTestJavaProcessBuilder(...) > > Tested by running tests with different jvm flags and tier1. This pull request has now been integrated. Changeset: d39b7bab Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/d39b7bab27af5ba24ff0925037b8e5fb99680dc0 Stats: 132 lines in 5 files changed: 12 ins; 59 del; 61 mod 8316460: 4 javax/management tests ignore VM flags Reviewed-by: kevinw ------------- PR: https://git.openjdk.org/jdk/pull/17764 From lmesnik at openjdk.org Fri Feb 9 18:42:58 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Feb 2024 18:42:58 GMT Subject: Integrated: 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 23:26:30 GMT, Leonid Mesnik wrote: > There are several .sh tests which use ${TESTVMOPTS} only. Updated them to use ${TESTJAVAOPTS} also. > Tested by running them with different options and tier1. This pull request has now been integrated. Changeset: 3ebe6c19 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb Stats: 35 lines in 14 files changed: 0 ins; 0 del; 35 mod 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only Reviewed-by: kevinw, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/17780 From duke at openjdk.org Fri Feb 9 18:43:08 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Fri, 9 Feb 2024 18:43:08 GMT Subject: RFR: 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root In-Reply-To: <2ofyu9f8afgL3MxQ4YeMk9Bk6p-a55rMOXlHq3Q41ZY=.d6d2606a-3a95-479e-8f0b-7ca87cf83575@github.com> References: <7vessvLp3h1VbXvYrU855MWBnK6MB0XLsQokmm6ynM4=.e97f68cc-efd7-4c83-a36f-4031d784e5b1@github.com> <2ofyu9f8afgL3MxQ4YeMk9Bk6p-a55rMOXlHq3Q41ZY=.d6d2606a-3a95-479e-8f0b-7ca87cf83575@github.com> Message-ID: On Fri, 9 Feb 2024 18:22:47 GMT, Kevin Walls wrote: >> Alright, sounds good to me. :) Thanks again for taking a look! >> >>> One other thing - JDK-8226919 looks like the original bug for this, logged a few years back, so if this fixes both, the record should show that it fixes that one, and JDK-8307977 should be closed as a duplicate. I/somebody can take care of that JBS admin. But if this PR could be associated with only JDK-8226919 that would be simple. >> >> I'll still fix this. So, I should change the PR title to match JDK-8226919, and issue an `/issue remove` command for JDK-8307977, is that correct? >> >> Once that is done, I would kindly ask for someone sponsoring this change as well. > >> I'll still fix this. So, I should change the PR title to match JDK-8226919, and issue an `/issue remove` command for JDK-8307977, is that correct? > > Yes exactly, thanks. Thank you @kevinjwalls and @jerboaa for reviewing and guiding me through this process, this was a great as a first-time JDK contributor! One more question, can I do anything to help getting this backported to e.g. 21 and 17? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1936426583 From lmesnik at openjdk.org Fri Feb 9 18:42:57 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Feb 2024 18:42:57 GMT Subject: RFR: 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 23:26:30 GMT, Leonid Mesnik wrote: > There are several .sh tests which use ${TESTVMOPTS} only. Updated them to use ${TESTJAVAOPTS} also. > Tested by running them with different options and tier1. @kevinjwalls, @plummercj Thank you for review. I run tests with all options used for testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17780#issuecomment-1936424752 From amenkov at openjdk.org Fri Feb 9 20:42:14 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 9 Feb 2024 20:42:14 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow [v2] In-Reply-To: References: Message-ID: > The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). > The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. > > testing: > - sanity tier1; > - all RedefineClasses/RetransformClasses 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 Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: logging on cp overflow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17759/files - new: https://git.openjdk.org/jdk/pull/17759/files/31b31fe8..a726ea8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17759&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17759&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17759/head:pull/17759 PR: https://git.openjdk.org/jdk/pull/17759 From lmesnik at openjdk.org Fri Feb 9 21:49:05 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Feb 2024 21:49:05 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow [v2] In-Reply-To: References: Message-ID: <-mEjKepIWU-ts9a6UcEBaaHD5NblLIij7y5kUrvyNMU=.312555fb-b584-4f7a-92d2-a1cd418e8ff5@github.com> On Fri, 9 Feb 2024 20:42:14 GMT, Alex Menkov wrote: >> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). >> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. >> >> testing: >> - sanity tier1; >> - all RedefineClasses/RetransformClasses 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 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > logging on cp overflow Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17759#pullrequestreview-1873242113 From amenkov at openjdk.org Fri Feb 9 21:49:06 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 9 Feb 2024 21:49:06 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow [v2] In-Reply-To: <8jAkfYsTL8RV4jg3_dXfQZaTp4BP_wx9scBRt1nWl6A=.85bc28e0-6c17-4964-91d0-d25d6cee4cca@github.com> References: <8jAkfYsTL8RV4jg3_dXfQZaTp4BP_wx9scBRt1nWl6A=.85bc28e0-6c17-4964-91d0-d25d6cee4cca@github.com> Message-ID: On Fri, 9 Feb 2024 03:27:54 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1828: >> >>> 1826: // ensure merged constant pool size does not overflow u2 >>> 1827: if (merge_cp_length > 0xFFFF) { >>> 1828: return JVMTI_ERROR_INTERNAL; >> >> Doesn't it make a sense to add some logging there so user could easier understand the problem? > > Seems like a good idea, you can use log_warning(redefine, class, constantpool)("...") Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17759#discussion_r1484834110 From sspitsyn at openjdk.org Fri Feb 9 22:01:07 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Feb 2024 22:01:07 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: <8loJ_hZVW1c4wCOAgx0CM9mP664mZ9CEKSvq_2Bj80o=.3952807a-c155-4a2f-860c-0fb3f4c13339@github.com> On Thu, 8 Feb 2024 15:29:47 GMT, Daniel D. Daugherty wrote: >> Yes, I've figured this out now. Thank you for pointing to it. >> It feels, the counts can be calculated correctly without touching the implementation of `current_pending_monitor()`, `current_waiting_monitor()`, `_contensions` and `_waiters`. >> At least, I'll try to fix it locally in the `JvmtiEnvBase::get_object_monitor_usage()`. >> Please, let me know what do you prefer. > > I don't have a preference (yet). Like what David suggested, I think we need to > determine the list of thread and monitor interaction scenarios that want to > exercise with this API. Once we're happy that those scenarios represent the > complete list of possible combinations we should double check that against the > API spec to make sure that those scenarios cover the API spec. Finally, we need > to make sure that we have a test that covers all those scenarios. > > It has been a long, long time since I've looked at those NSK tests... :-( Thank you, Dan! I have a fix and will push it after the mach5 tiers testing. I've extended the test `test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003` to have all combinations that David suggested but it was a little bit tricky to make it stable. It feels that an update of the current_pending_monitor() to report the re-entered monitors would make it more elegant. But I'm not sure how to do it correctly yet. Also, I've noticed we do not post the JVMTI events `MonitorContendedEnter` and `MonitorContendedEntered` for the re-enter case. It looks like a bug to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1484843163 From coleenp at openjdk.org Fri Feb 9 22:29:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Feb 2024 22:29:04 GMT Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow [v2] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 20:42:14 GMT, Alex Menkov wrote: >> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). >> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. >> >> testing: >> - sanity tier1; >> - all RedefineClasses/RetransformClasses 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 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > logging on cp overflow Yes, this should definitely be tagged noreg-hard. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17759#pullrequestreview-1873283771 From amenkov at openjdk.org Sat Feb 10 00:59:58 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 10 Feb 2024 00:59:58 GMT Subject: Integrated: JDK-8311076: RedefineClasses doesn't check for ConstantPool overflow In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 20:53:53 GMT, Alex Menkov wrote: > The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned). > The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references. > > testing: > - sanity tier1; > - all RedefineClasses/RetransformClasses 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 This pull request has now been integrated. Changeset: e33d8a21 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/e33d8a219811930492e684e19a73dadb09590052 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8311076: RedefineClasses doesn't check for ConstantPool overflow Reviewed-by: coleenp, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/17759 From sspitsyn at openjdk.org Sat Feb 10 04:06:37 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Feb 2024 04:06:37 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/3d735722..69ba5e7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=02-03 Stats: 155 lines in 8 files changed: 64 ins; 36 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From sspitsyn at openjdk.org Sat Feb 10 07:55:07 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Feb 2024 07:55:07 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:05:38 GMT, David Holmes wrote: > I think the only way to make sense of this is to actually set up scenarios where we have different threads contending on entry, different threads waiting and different threads re-entering after being notified, and see what values actually get returned in each case. I've added this kind of test coverage to the test NSK test: `test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003` > I think the `pending_current_monitor` issue may be a distinct/different issue. I tried to find a solution fix the `pending_current_monitor` to cover the monitor re-enter case and found that it is not clear how to do it in a straight-forward way. So, decide to leave it alone for now. However, it seems, it could be more elegant to fix this function. I still can make it a try to do that if you give me some hints or ideas on how to do it better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1936920693 From sspitsyn at openjdk.org Sat Feb 10 08:17:02 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Feb 2024 08:17:02 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: References: Message-ID: <11HkrzU483RNyYcWEz5-6Qh9p7MlFoqNZu3kiGvwHOQ=.54d4bda7-16f2-4722-a8a3-b718071e40a7@github.com> On Sat, 10 Feb 2024 04:06:37 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 I've pushed an update addressing review comments from Dan/David. This is a short list describing the updates: - now the function `Threads::get_pending_threads()` in the `threads.cpp` is supporting the monitor re-enter case - introduced the function `oop JavaThread::vthread_or_thread()` used in the function `Threads::get_pending_threads()` - the fix in `jvmtiEnvBase.cpp` has been re-arranged to calculate early the right sizes of the `waiters` and `notify_waiters` array - the NSK test `test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003` was extended to provide coverage suggested by David. It recreates a scenario with several threads blocked on the monitor enter, several threads blocked on re-enter and several thread waiting in the `Object.wait()` to be notified. - some small test fixes suggested in review The mach5 tiers 1-6 are all passed except the four known to fail JCK tests in the tier 6. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1936927038 From duke at openjdk.org Sat Feb 10 14:10:05 2024 From: duke at openjdk.org (Yifeng Jin) Date: Sat, 10 Feb 2024 14:10:05 GMT Subject: Integrated: 8325464: GCCause.java out of sync with gcCause.hpp In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 06:19:16 GMT, Yifeng Jin wrote: > These two files (`GCCause.java` and `gcCause.hpp`) should be in sync by design, see comments in these two files. However, some recent changes (e.g. [JDK-8240239](https://bugs.openjdk.org/browse/JDK-8240239)) to `gcCause.hpp` were not simultaneously reflected in `GCCause.java`. This patch updates `GCCause.java` to keep sync with latest `gcCause.hpp`. This pull request has now been integrated. Changeset: 71d2dbd0 Author: yifeng.jyf Committer: Denghui Dong URL: https://git.openjdk.org/jdk/commit/71d2dbd0b637b75a98115b6d867669b574d7baa8 Stats: 19 lines in 1 file changed: 9 ins; 7 del; 3 mod 8325464: GCCause.java out of sync with gcCause.hpp Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/17766 From ihse at openjdk.org Mon Feb 12 08:01:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:01:23 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'master' into jdk-FOB64 - Fix indentation - Once more, remove AIX dirent64 et al defines - Also fix fstatvfs on AIX - Redefine statvfs as statvfs64 on AIX - Add kludge to BufferedRenderPipe.c for AIX - Merge branch 'master' into jdk-FOB64 - Remove all system includes from debug_util.h - Merge branch 'master' into jdk-FOB64 - Move #include out of debug_util.h - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b ------------- Changes: https://git.openjdk.org/jdk/pull/17538/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=10 Stats: 284 lines in 29 files changed: 23 ins; 144 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Mon Feb 12 08:09:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:09:34 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v12] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/caccbf9b..7f673ef6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=10-11 Stats: 26 lines in 26 files changed: 0 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Mon Feb 12 08:09:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:09:34 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote: >> And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. >> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes. > >> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it. > > Same as `statvfs`. Only the file system ID field is smaller. @JoKern65 @MBaesken I did not receive any reply about what to do with `fstatvfs`, so I decided to keep the last verified change for AIX. If you want to clean this up, then please do so, but at that time it will be an AIX-only patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938201250 From duke at openjdk.org Mon Feb 12 08:09:36 2024 From: duke at openjdk.org (Sam James) Date: Mon, 12 Feb 2024 08:09:36 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11] In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 08:01:23 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into jdk-FOB64 > - Fix indentation > - Once more, remove AIX dirent64 et al defines > - Also fix fstatvfs on AIX > - Redefine statvfs as statvfs64 on AIX > - Add kludge to BufferedRenderPipe.c for AIX > - Merge branch 'master' into jdk-FOB64 > - Remove all system includes from debug_util.h > - Merge branch 'master' into jdk-FOB64 > - Move #include out of debug_util.h > - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b Thank you again for this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938202537 From ihse at openjdk.org Mon Feb 12 08:09:36 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:09:36 GMT Subject: Integrated: 8324539: Do not use LFS64 symbols in JDK libs In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. This pull request has now been integrated. Changeset: e5cb78cc Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/e5cb78cc88761cd27964e9fe77fc9c6f9073e888 Stats: 310 lines in 29 files changed: 23 ins; 144 del; 143 mod 8324539: Do not use LFS64 symbols in JDK libs Reviewed-by: jwaters, erikj, mbaesken, alanb ------------- PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Mon Feb 12 08:11:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:11:03 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: <8BLLuuu7gTj4P8bDZ40PWRJDT7668CSSqMiywzlPrIs=.1f188e66-2327-43e3-b30e-16798937eefe@github.com> On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato wrote: >> This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. >> >> With Skara jcheck, it is possible to increase the coverage of the whitespace checks. >> >> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. > > Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces. @naotoj Thanks! Would you care to also submit a review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1938204446 From jkern at openjdk.org Mon Feb 12 09:26:14 2024 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 12 Feb 2024 09:26:14 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote: >> And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. >> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes. > >> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it. > > Same as `statvfs`. Only the file system ID field is smaller. > @JoKern65 @MBaesken I did not receive any reply about what to do with `fstatvfs`, so I decided to keep the last verified change for AIX. If you want to clean this up, then please do so, but at that time it will be an AIX-only patch. @magicus I have to reach out to IBM asking if the different size of the 'filesystem ID' field in statvfs makes an important difference. If not, I will remove the defines in an AIX-only patch. Thanks a lot for your effort. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938300228 From sgehwolf at openjdk.org Mon Feb 12 09:28:11 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 12 Feb 2024 09:28:11 GMT Subject: RFR: 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root In-Reply-To: References: <7vessvLp3h1VbXvYrU855MWBnK6MB0XLsQokmm6ynM4=.e97f68cc-efd7-4c83-a36f-4031d784e5b1@github.com> <2ofyu9f8afgL3MxQ4YeMk9Bk6p-a55rMOXlHq3Q41ZY=.d6d2606a-3a95-479e-8f0b-7ca87cf83575@github.com> Message-ID: On Fri, 9 Feb 2024 18:40:04 GMT, Sebastian L?vdahl wrote: > One more question, can I do anything to help getting this backported to e.g. 21 and 17? First, I suggest to wait a few weeks in order to see if there are any follow-up bugs which show up in testing in mainline. Then start backporting it to 22u, then 21u, then 17u (in that order). A few references: https://openjdk.org/guide/#backporting https://wiki.openjdk.org/display/JDKUpdates/JDK+21u ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1938303184 From sroy at openjdk.org Mon Feb 12 09:38:21 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 12 Feb 2024 09:38:21 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v18] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: update comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/f4b85357..ca75a337 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=16-17 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From ihse at openjdk.org Mon Feb 12 15:45:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 15:45:15 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" Message-ID: There are several places in hotspot where an internal function should have been declared static, but isn't. These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: a) is declared static, or b) has a declaration before its definition. The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. This is the first part of addressing these issues, where all places that are trivially missing static are fixed. I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I think this is mostly a good thing. Finally, I have manually searched for each and every one of these functions (tedious!) and verified that they are indeed only called from within the specific file. But in the end, the proof should be in the pudding -- if hotspot still compiles with these changes, then they should be correct. (The one exception to this is if the symbol is supposed to be used in e.g. the debugger, and I've missed that.) ------------- Commit messages: - 8252136: Several methods in hotspot are missing "static" Changes: https://git.openjdk.org/jdk/pull/17806/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17806&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8252136 Stats: 204 lines in 72 files changed: 6 ins; 2 del; 196 mod Patch: https://git.openjdk.org/jdk/pull/17806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17806/head:pull/17806 PR: https://git.openjdk.org/jdk/pull/17806 From coleenp at openjdk.org Mon Feb 12 16:02:02 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 12 Feb 2024 16:02:02 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie wrote: > There are several places in hotspot where an internal function should have been declared static, but isn't. > > These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: > a) is declared static, or > b) has a declaration before its definition. > > The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. > > This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. > > This is the first part of addressing these issues, where all places that are trivially missing static are fixed. > > I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. > > When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi... Nice change. I looked at the runtime files, and surprised there weren't more. Thank you. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1875580015 From stefank at openjdk.org Mon Feb 12 16:51:03 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 12 Feb 2024 16:51:03 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie wrote: > There are several places in hotspot where an internal function should have been declared static, but isn't. > > These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: > a) is declared static, or > b) has a declaration before its definition. > > The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. > > This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. > > This is the first part of addressing these issues, where all places that are trivially missing static are fixed. > > I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. > > When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi... The argument alignment is wonky after this patch. Could you go over the patch and fix that? ------------- Changes requested by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1875713907 From sroy at openjdk.org Mon Feb 12 17:25:15 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 12 Feb 2024 17:25:15 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14] In-Reply-To: <1kzsCJOR4U-lc77vCBrS_Oa4YCoBv5a7Zz8gKDHDuXg=.9471c3b3-cea7-415b-aa18-79aa76f508d1@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <1kzsCJOR4U-lc77vCBrS_Oa4YCoBv5a7Zz8gKDHDuXg=.9471c3b3-cea7-415b-aa18-79aa76f508d1@github.com> Message-ID: On Thu, 8 Feb 2024 14:39:24 GMT, Martin Doerr wrote: > > > The trailing whitespace errors must get fixed (integration blocker). > > > > > > I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ? > > Strange. I don't see any whitespace problem, either. Maybe it's possible to rerun jcheck (GitHub Actions). Otherwise, you may need to create a new PR. Re running tests is not helping as i made more commits. Not sure why it arrived all of a sudden. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1939190557 From naoto at openjdk.org Mon Feb 12 17:37:56 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 12 Feb 2024 17:37:56 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. > > With Skara jcheck, it is possible to increase the coverage of the whitespace checks. > > However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. > @naotoj Thanks! Would you care to also submit a review? My bad. I thought I approved this PR. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875811619 From sroy at openjdk.org Mon Feb 12 17:41:14 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 12 Feb 2024 17:41:14 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v19] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Check to revert commit and do jcheck ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/ca75a337..b5cf57d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=17-18 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From dfuchs at openjdk.org Mon Feb 12 17:42:06 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 12 Feb 2024 17:42:06 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. > > With Skara jcheck, it is possible to increase the coverage of the whitespace checks. > > However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. Approving the sun.net changes. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875818676 From sroy at openjdk.org Mon Feb 12 17:51:18 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 12 Feb 2024 17:51:18 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v20] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: revert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/b5cf57d6..ecf8ad6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=18-19 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From sroy at openjdk.org Mon Feb 12 17:55:23 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 12 Feb 2024 17:55:23 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v21] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: revert log_info ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/ecf8ad6c..d887ad73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=19-20 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From sroy at openjdk.org Mon Feb 12 18:04:21 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 12 Feb 2024 18:04:21 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Remove not matched trailing whitespaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/d887ad73..c6332f67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=20-21 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From kvn at openjdk.org Mon Feb 12 18:05:06 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 Feb 2024 18:05:06 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" In-Reply-To: References: Message-ID: <8A0cHKrgXY3iuAIKiZx-SeqshSWLSMNtuE6wf86oiLE=.dcbd9e4d-428f-4a98-a0c3-8d9da9338dec@github.com> On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie wrote: > There are several places in hotspot where an internal function should have been declared static, but isn't. > > These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: > a) is declared static, or > b) has a declaration before its definition. > > The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. > > This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. > > This is the first part of addressing these issues, where all places that are trivially missing static are fixed. > > I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. > > When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi... I reviewed compiler code (cpu/, compiler/, c1/, opto/). Looks good to me. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1875862288 From sroy at openjdk.org Mon Feb 12 18:12:08 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 12 Feb 2024 18:12:08 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <1kzsCJOR4U-lc77vCBrS_Oa4YCoBv5a7Zz8gKDHDuXg=.9471c3b3-cea7-415b-aa18-79aa76f508d1@github.com> Message-ID: On Mon, 12 Feb 2024 17:21:55 GMT, Suchismith Roy wrote: > > > > The trailing whitespace errors must get fixed (integration blocker). > > > > > > > > > I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ? > > > > > > Strange. I don't see any whitespace problem, either. Maybe it's possible to rerun jcheck (GitHub Actions). Otherwise, you may need to create a new PR. > > Re running tests is not helping as i made more commits. Not sure why it arrived all of a sudden. I have resolved this, I reverted back to old commit where assert was present. Then brought it back to current state. Saw that there was one line with some trailing whitespaces, using sed command with valid regex. But the jcheck was pointing at the wrong line , which was confusing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1939268192 From kbarrett at openjdk.org Mon Feb 12 20:09:58 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 12 Feb 2024 20:09:58 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie wrote: > There are several places in hotspot where an internal function should have been declared static, but isn't. > > These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: > a) is declared static, or > b) has a declaration before its definition. > > The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. > > This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. > > This is the first part of addressing these issues, where all places that are trivially missing static are fixed. > > I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. > > When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi... Mostly good, other than the parameter indentation issue mentioned by @stefank . Just a couple of minor comments. src/hotspot/share/c1/c1_LinearScan.cpp line 1449: > 1447: } > 1448: > 1449: #ifdef ASSERT I think the change from PRODUCT to ASSERT might be incorrect, and might break "optimize" builds. src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp line 202: > 200: static RootDescriptionInfo* root_infos = nullptr; > 201: > 202: static int __write_sample_info__(JfrCheckpointWriter* writer, const void* si) { pre-existing: all these names starting with underscores are technically reserved names - C++14 17.6.4.3.2. Shouldn't be changed as part of this PR, but perhaps there should be a bug report? Don't know if anyone would ever get around to doing anything about it though. src/hotspot/share/runtime/sharedRuntimeTrans.cpp line 443: > 441: ivln2_l = 1.92596299112661746887e-08; /* 0x3E54AE0B, 0xF85DDF44 =1/ln2 tail*/ > 442: > 443: static double __ieee754_pow(double x, double y) { pre-existing: another batch of technically reserved names in this file. ------------- PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1876043818 PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1486684672 PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1486678063 PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1486694230 From joehw at openjdk.org Mon Feb 12 20:26:00 2024 From: joehw at openjdk.org (Joe Wang) Date: Mon, 12 Feb 2024 20:26:00 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:46:06 GMT, Magnus Ihse Bursie wrote: >> This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. >> >> With Skara jcheck, it is possible to increase the coverage of the whitespace checks. >> >> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. > > src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24: > >> 22: # Messages for message reporting >> 23: BadMessageKey = The error message corresponding to the message key can not be found. >> 24: FormatFailed = An internal error occurred while formatting the following message:\n > > Same here with `:\n`... It's done with the code (that is, a key is appended with the code). In fact, the whole Xerces stack was implemented this way. I'd leave it as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1486731927 From joehw at openjdk.org Mon Feb 12 20:25:59 2024 From: joehw at openjdk.org (Joe Wang) Date: Mon, 12 Feb 2024 20:25:59 GMT Subject: RFR: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. > > With Skara jcheck, it is possible to increase the coverage of the whitespace checks. > > However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. java.xml changes look fine to me. ------------- Marked as reviewed by joehw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1876181019 From sspitsyn at openjdk.org Tue Feb 13 07:11:18 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Feb 2024 07:11:18 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v5] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge - review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 - Merge - review: thread in notify waiter list can't be BLOCKED - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/69ba5e7e..182cd07c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=03-04 Stats: 6592 lines in 396 files changed: 3981 ins; 1259 del; 1352 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From dholmes at openjdk.org Tue Feb 13 07:11:19 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Feb 2024 07:11:19 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: References: Message-ID: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> On Sat, 10 Feb 2024 04:06:37 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 Sorry really struggling to understand this now. We have gone from a simple miscalculation to apparently doing everything wrong. IIUC this API does not currently handle virtual threads correctly -i s that the case? If so I would like to see that fix factored out and done separately before this fix is done. Thanks. src/hotspot/share/runtime/javaThread.cpp line 196: > 194: oop JavaThread::vthread_or_thread() const { > 195: oop result = vthread(); > 196: if (result == nullptr) { Is that really sufficient? If so why do we have `is_vthread_mounted` which checks the continuation? test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 31: > 29: > 30: final static int JCK_STATUS_BASE = 95; > 31: final static int NUMBER_OF_ENTERER_THREADS = 4; Nit: ENTERING not ENTERER test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 33: > 31: final static int NUMBER_OF_ENTERER_THREADS = 4; > 32: final static int NUMBER_OF_WAITER_THREADS = 4; > 33: final static int NUMBER_OF_THREADS = NUMBER_OF_ENTERER_THREADS + NUMBER_OF_WAITER_THREADS; This testing is not sufficient. We have three states of interest: - entering the monitor directly - waiting in the monitor via Object.wait - re-rentering the monitor after being notified (or timed-out or interrupted) - we need to check all of these conditions in permutations covering zero and non-zero for each one, and then see that we get the correct counts back from JVM TI. ------------- PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1876986745 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487299437 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487304912 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487311675 From mdoerr at openjdk.org Tue Feb 13 07:28:07 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 13 Feb 2024 07:28:07 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Remove not matched trailing whitespaces Thanks for improving it! My points have been addressed. Up to other reviewers, now. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1877020968 From sspitsyn at openjdk.org Tue Feb 13 08:07:04 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Feb 2024 08:07:04 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: On Tue, 13 Feb 2024 07:00:41 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 31: > >> 29: >> 30: final static int JCK_STATUS_BASE = 95; >> 31: final static int NUMBER_OF_ENTERER_THREADS = 4; > > Nit: ENTERING not ENTERER Okay, thanks. Will rename it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487366808 From sspitsyn at openjdk.org Tue Feb 13 08:15:03 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Feb 2024 08:15:03 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: <86Dgumz3_blIZl8YfNNNsAKef0po-ZwbZT9wbN5egjE=.df7dc8aa-3528-4992-a857-a29eb26cc35d@github.com> On Tue, 13 Feb 2024 06:55:46 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 > > src/hotspot/share/runtime/javaThread.cpp line 196: > >> 194: oop JavaThread::vthread_or_thread() const { >> 195: oop result = vthread(); >> 196: if (result == nullptr) { > > Is that really sufficient? If so why do we have `is_vthread_mounted` which checks the continuation? Thank you for the question. This function does not care if this is a vthread, or not and if it is mounted or not. We just need a right oop of currently executed thread or vthread. The `threadOop()` and `vthread()` can return the same oop. If `vthread()` is not `nullptr` then it can point either to a `j.l.Thread` or a `j.lVirtualThread`. If it is `nullptr` then we have to take `threadOop()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487374609 From sspitsyn at openjdk.org Tue Feb 13 08:39:03 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Feb 2024 08:39:03 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: On Tue, 13 Feb 2024 07:06:05 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 33: > >> 31: final static int NUMBER_OF_ENTERER_THREADS = 4; >> 32: final static int NUMBER_OF_WAITER_THREADS = 4; >> 33: final static int NUMBER_OF_THREADS = NUMBER_OF_ENTERER_THREADS + NUMBER_OF_WAITER_THREADS; > > This testing is not sufficient. We have three states of interest: > - entering the monitor directly > - waiting in the monitor via Object.wait > - re-rentering the monitor after being notified (or timed-out or interrupted) > - we need to check all of these conditions in permutations covering zero and non-zero for each one, and then see that we get the correct counts back from JVM TI. Thank you for the comment, David. Now the test checks: - the threads waiting to enter the monitor are returned correctly with all permutations of threads waiting to be notified and threads waiting to re-enter the monitor Initially, there are 4 threads waiting to be notified and zero threads waiting to re-enter the monitor. They are notified one by with the subsequent checks, so all the pairs are checked ``: `<0,4>, <1,3>, <2,2>, <3,1>, <4,0>` I'm not sure why do you think all permutations covering zero and non-zero for each one are needed. At least, it looks like an overkill to me. But if you still think it is really important then I can add cases with zero threads waiting to enter the monitor with the same permutations of threads waiting to be notified and threads re-entering the monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487402314 From sspitsyn at openjdk.org Tue Feb 13 08:42:02 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Feb 2024 08:42:02 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: On Tue, 13 Feb 2024 07:08:33 GMT, David Holmes wrote: > Sorry really struggling to understand this now. We have gone from a simple miscalculation to apparently doing everything wrong. IIUC this API does not currently handle virtual threads correctly - is that the case? If so I would like to see that fix factored out and done separately before this fix is done. Thanks. Thank you for the concern, David. But it is not clear what it is. Could you, please, explain a little bit? Why do you think the virtual threads are handled incorrectly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1940760918 From ihse at openjdk.org Tue Feb 13 10:03:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 13 Feb 2024 10:03:08 GMT Subject: Integrated: 8325558: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: <1_5f_JhU7k2LuEKn7w-rn3FkkBpaBDiz3o_uBy-uKiw=.7ed5bef7-6484-435f-8d87-12dadc4d9e9d@github.com> On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in JDK-8295729: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. > > With Skara jcheck, it is possible to increase the coverage of the whitespace checks. > > However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck. This pull request has now been integrated. Changeset: c266800a Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/c266800a3a7dd44416b0b4df3bdd78410241d74b Stats: 761 lines in 95 files changed: 0 ins; 5 del; 756 mod 8325558: Add jcheck whitespace checking for properties files Reviewed-by: naoto, dfuchs, joehw ------------- PR: https://git.openjdk.org/jdk/pull/17789 From ihse at openjdk.org Tue Feb 13 10:34:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 13 Feb 2024 10:34:19 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 19:44:46 GMT, Kim Barrett wrote: >> There are several places in hotspot where an internal function should have been declared static, but isn't. >> >> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: >> a) is declared static, or >> b) has a declaration before its definition. >> >> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. >> >> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. >> >> This is the first part of addressing these issues, where all places that are trivially missing static are fixed. >> >> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. >> >> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not disc... > > src/hotspot/share/c1/c1_LinearScan.cpp line 1449: > >> 1447: } >> 1448: >> 1449: #ifdef ASSERT > > I think the change from PRODUCT to ASSERT might be incorrect, and might break "optimize" builds. Actually, it is the other way around. Without this change, optimized builds broke. This function is only called from within an assert(), and these are defined as no-ops in optimized builds. Thus, this function was never called and gcc complained about dead code. > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp line 202: > >> 200: static RootDescriptionInfo* root_infos = nullptr; >> 201: >> 202: static int __write_sample_info__(JfrCheckpointWriter* writer, const void* si) { > > pre-existing: all these names starting with underscores are technically reserved names - C++14 17.6.4.3.2. > Shouldn't be changed as part of this PR, but perhaps there should be a bug report? Don't know if anyone > would ever get around to doing anything about it though. Please feel free to open a bug report. ? Unless there is a warning flag to avoid creating reserved names (is there?), it is more of a matter of coding style on the part of Hotspot, and that is basically where I draw the line of my meddling with Hotspot. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1487573865 PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1487571483 From ihse at openjdk.org Tue Feb 13 11:05:30 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 13 Feb 2024 11:05:30 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2] In-Reply-To: References: Message-ID: > There are several places in hotspot where an internal function should have been declared static, but isn't. > > These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: > a) is declared static, or > b) has a declaration before its definition. > > The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. > > This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. > > This is the first part of addressing these issues, where all places that are trivially missing static are fixed. > > I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. > > When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi... Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Revert spurious changes in non-modified file - Fix indentation issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17806/files - new: https://git.openjdk.org/jdk/pull/17806/files/97595a3e..9702d84a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17806&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17806&range=00-01 Stats: 32 lines in 13 files changed: 3 ins; 0 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/17806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17806/head:pull/17806 PR: https://git.openjdk.org/jdk/pull/17806 From ihse at openjdk.org Tue Feb 13 11:05:30 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 13 Feb 2024 11:05:30 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2] In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 16:47:59 GMT, Stefan Karlsson wrote: > The argument alignment is wonky after this patch. Could you go over the patch and fix that? I did not think of that, sorry. Fixed now. (It turned out that not all places were properly aligned even before my patch...) There are some places with extremely long lines, but that seem to be the style in these files, so I did not introduce line breaks there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17806#issuecomment-1941218340 From jkern at openjdk.org Tue Feb 13 12:12:10 2024 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 13 Feb 2024 12:12:10 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Remove not matched trailing whitespaces Everything is OK for me now. ------------- Marked as reviewed by jkern (Author). PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1877784574 From ysr1729 at gmail.com Tue Feb 13 18:49:58 2024 From: ysr1729 at gmail.com (ysr1729 at gmail.com) Date: Tue, 13 Feb 2024 10:49:58 -0800 Subject: Call for Discussion: New Project: Skogsluft In-Reply-To: References: Message-ID: <57D51098-7D05-4C86-A9C7-EEC8760BAFE8@gmail.com> Excellent initiative, thank you! A couple of drive-by remarks: 1. Seems to naturally belong in the Serviceability group (hereby cc?d), who appear to me to be natural sponsors of such an effort 2. I notice in the census (openjdk.org/census#serviceability) that some portion of the Serviceability group?s membership has likely retired or moved to working on other things. Does it perhaps makes sense to grow the group membership with those actively involved in Serviceability-related efforts these days? / Ramki (OpenJDK: ysr) Sent from my iPhone > On Feb 2, 2024, at 9:15?AM, Jaroslav Bachor?k wrote: > > ? > I hereby invite discussion of a new Project, "Skogsluft," whose primary goal will be to improve Java's profiling capabilities within Java Flight Recorder (JFR). This project aims to introduce advanced profiling features that bridge the gap between Java and native code execution, and offer more precise and flexible profiling options. > > The focus will be on three key enhancements: > > 1. An improved stackwalker, capable of seamlessly walking mixed Java/native stacks. This will provide developers with a more coherent view of the stack traces, especially in applications where Java and native codes are interwoven. > > 2. A flexible CPU sampler scheduler. On Linux, this will be based on perf_event_open or timer_create systems, and on MacOS, we will utilize itimer. For other operating systems, the system will fall back to standard execution samples. This enhancement aims to offer more accurate and adaptable CPU sampling, taking into account the diverse environments in which Java applications run. > > 3. Labelling support for JFR. This will allow developers to set per-thread key-value labels that are automatically incorporated into any JFR event. Such labelling will provide richer context in profiling data, enabling more targeted analysis and debugging. > > To implement these enhancements, the "Skogsluft" will extend Java's profiling capabilities in JFR with the following approaches: > > Development of a cross-platform stackwalker that integrates native and Java stack frames, ensuring compatibility and efficiency across different operating systems. > > Design and integration of a scheduler for CPU sampling that adapts to the underlying operating system's capabilities, offering both precision and performance. > > Extension of the JFR API to support easy and flexible labelling of threads, ensuring that these labels are consistently captured in profiling data. > > I am looking for an OpenJDK group willing to sponsor this project and provide a person to lead this project. > > For the "Skogsluft" this Project will start with a clone of the current JDK main-line release, JDK 23, and track main-line releases going forward. The project will involve creating a separate repository for the development of these new profiling features, ensuring they are compatible and well-integrated with existing JFR functionalities. > > The "Skogsluft" is expected to deliver the features over time, in a series of JEPs (JDK Enhancement Proposals) that will likely span multiple feature releases. The aim is to eventually integrate these profiling improvements into the standard JDK distributions, enhancing the capabilities of JFR and providing developers with more powerful tools for performance analysis and debugging. > > With regards, > > Jaroslav Bachorik From dchuyko at openjdk.org Tue Feb 13 22:07:19 2024 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Tue, 13 Feb 2024 22:07:19 GMT Subject: RFR: 8309271: A way to align already compiled methods with compiler directives [v25] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 21:12:19 GMT, Dmitry Chuyko wrote: >> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack. >> >> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers. >> >> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods). >> >> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter. >> >> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them. >> >> In addition, a new diagnostic command `Compiler.replace_directives... > > Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: > > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Deopt osr, cleanups > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - ... and 33 more: https://git.openjdk.org/jdk/compare/5b9b176c...ea0322cd @sspitsyn Can I please have someone from serviceability group take a look at this? Comments from Paul and Andrei have been addressed a while ago. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14111#issuecomment-1942717023 From dcubed at openjdk.org Tue Feb 13 22:34:03 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 13 Feb 2024 22:34:03 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: On Tue, 13 Feb 2024 08:39:38 GMT, Serguei Spitsyn wrote: >> Sorry really struggling to understand this now. We have gone from a simple miscalculation to apparently doing everything wrong. >> >> IIUC this API does not currently handle virtual threads correctly -i s that the case? If so I would like to see that fix factored out and done separately before this fix is done. Thanks. > >> Sorry really struggling to understand this now. We have gone from a simple miscalculation to apparently doing everything wrong. IIUC this API does not currently handle virtual threads correctly - is that the case? If so I would like to see that fix factored out and done separately before this fix is done. Thanks. > > Thank you for the concern, David. But it is not clear what it is. Could you, please, explain a little bit? > Why do you think the virtual threads are handled incorrectly? @sspitsyn - When you get the chance, can you checkout these possible changes for the objmonusage001 test? https://github.com/openjdk/jdk/pull/17839 Summary of my test changes: - extend the check() function to verify more of the jvmtiMonitorUsage fields - add detailed comments at each of the verification points so it's clear what is being verified and why - add a better summary for the overall test - make it clear which output lines document failures I've also made some temporary debugging changes that are only useful while updating this test: - temporarily use the "printdump" parameter to enable test output - add a flag to verify the current JVMs bad jvmtiMonitorUsage fields so that the test can pass with an unmodified JVM - add a flag to add a delay that helps check for a lack of races in the verification points These proposed test changes help document how I think the GetObjectMonitorUsage API is supposed to work on a simple test case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1942747157 From dholmes at openjdk.org Wed Feb 14 02:26:05 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Feb 2024 02:26:05 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v5] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 07:11:18 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge > - review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 > - Merge > - review: thread in notify waiter list can't be BLOCKED > - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage > Why do you think the virtual threads are handled incorrectly? Sorry my mistake. The `thread_or_vthread` changes had me confused. src/hotspot/share/runtime/threads.cpp line 1200: > 1198: if (pending == monitor || > 1199: (waiting == monitor && JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER == > 1200: java_lang_Thread::get_thread_status(p->vthread_or_thread())) This code seems extremely racy. Is there anything that is stopping the target thread from running while we attempt this inspection of the oop state? If it was waiting and was interrupted or timed-out then we could mistakenly think it was still pending entry to this monitor when in fact it is not. It is also a shame that we have to reach up into the oop thread state to figure out if if it is blocked on re-entry ... ------------- PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1879239973 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1488808389 From dholmes at openjdk.org Wed Feb 14 02:26:05 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Feb 2024 02:26:05 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: <2iPk6kfykXqnv2hTa6GyvRTcI71om0C6X3Z0bZZMaOM=.1b6f9718-dc85-4b09-8cb1-5d53f1cb0a36@github.com> On Tue, 13 Feb 2024 08:34:57 GMT, Serguei Spitsyn wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 33: >> >>> 31: final static int NUMBER_OF_ENTERER_THREADS = 4; >>> 32: final static int NUMBER_OF_WAITER_THREADS = 4; >>> 33: final static int NUMBER_OF_THREADS = NUMBER_OF_ENTERER_THREADS + NUMBER_OF_WAITER_THREADS; >> >> This testing is not sufficient. We have three states of interest: >> - entering the monitor directly >> - waiting in the monitor via Object.wait >> - re-rentering the monitor after being notified (or timed-out or interrupted) >> - we need to check all of these conditions in permutations covering zero and non-zero for each one, and then see that we get the correct counts back from JVM TI. > > Thank you for the comment, David. > Now the test checks: > - the threads waiting to enter the monitor are returned correctly with all permutations of threads waiting to be notified and threads waiting to re-enter the monitor > Initially, there are 4 threads waiting to be notified and zero threads waiting to re-enter the monitor. > They are notified one by with the subsequent checks, so all the pairs are checked ``: `<0,4>, <1,3>, <2,2>, <3,1>, <4,0>` > > I'm not sure why do you think all permutations covering zero and non-zero for each one are needed. > At least, it looks like an overkill to me. But if you still think it is really important then I can add cases with zero threads waiting to enter the monitor with the same permutations of threads waiting to be notified and threads re-entering the monitor. If you don't check all the zero/non-zero permutations for the three counts of interest then you don't know that you are combining them the right way to give the two counts reported by the API. Note that checking "all the pairs" is not really necessary as all non-zero values fall in the same equivalence class for testing purposes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1488795667 From ihse at openjdk.org Wed Feb 14 09:48:06 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 Feb 2024 09:48:06 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2] In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 16:47:59 GMT, Stefan Karlsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert spurious changes in non-modified file >> - Fix indentation issues > > The argument alignment is wonky after this patch. Could you go over the patch and fix that? @stefank Is this version okay? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17806#issuecomment-1943403850 From stefank at openjdk.org Wed Feb 14 10:47:04 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Feb 2024 10:47:04 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 11:05:30 GMT, Magnus Ihse Bursie wrote: >> There are several places in hotspot where an internal function should have been declared static, but isn't. >> >> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: >> a) is declared static, or >> b) has a declaration before its definition. >> >> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. >> >> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. >> >> This is the first part of addressing these issues, where all places that are trivially missing static are fixed. >> >> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. >> >> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not disc... > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert spurious changes in non-modified file > - Fix indentation issues Marked as reviewed by stefank (Reviewer). Yes, the GC code looks good. Thanks! ------------- PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1879939402 PR Comment: https://git.openjdk.org/jdk/pull/17806#issuecomment-1943501692 From sspitsyn at openjdk.org Wed Feb 14 11:59:10 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Feb 2024 11:59:10 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v6] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: imported the suggestion extending the nsk/jvmti test objmonusage001 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/182cd07c..070b15d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=04-05 Stats: 133 lines in 3 files changed: 118 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From sspitsyn at openjdk.org Wed Feb 14 11:59:10 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Feb 2024 11:59:10 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: On Tue, 13 Feb 2024 22:30:56 GMT, Daniel D. Daugherty wrote: > When you get the chance, can you checkout these possible changes for the objmonusage001 test? Thanks, Dan. I've pushed the suggested test changes but refactored them a little bit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1943626874 From sspitsyn at openjdk.org Wed Feb 14 12:03:09 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Feb 2024 12:03:09 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v7] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fixed trailing spaces in one line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/070b15d1..674da98c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From sspitsyn at openjdk.org Wed Feb 14 12:19:05 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Feb 2024 12:19:05 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v5] In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 02:18:58 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge >> - review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003 >> - Merge >> - review: thread in notify waiter list can't be BLOCKED >> - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage > > src/hotspot/share/runtime/threads.cpp line 1200: > >> 1198: if (pending == monitor || >> 1199: (waiting == monitor && JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER == >> 1200: java_lang_Thread::get_thread_status(p->vthread_or_thread())) > > This code seems extremely racy. Is there anything that is stopping the target thread from running while we attempt this inspection of the oop state? If it was waiting and was interrupted or timed-out then we could mistakenly think it was still pending entry to this monitor when in fact it is not. > It is also a shame that we have to reach up into the oop thread state to figure out if if it is blocked on re-entry ... The function `get_pending_threads()` is executed only by the VM_GetObjectMonitorUsage operation. I've added this assert there: `assert(Thread::current()->is_VM_thread(), "Must be the VM thread");` Does it address your concern? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1489379382 From ayang at openjdk.org Wed Feb 14 13:19:14 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 14 Feb 2024 13:19:14 GMT Subject: RFR: 8325860: Serial: Move Generation.java to serial folder Message-ID: Relocate `Generation.java` to mirror the structure in hotspot. Also, specialize the logic to two concrete generations. Test: tier1-3 ------------- Commit messages: - sa-move-generation Changes: https://git.openjdk.org/jdk/pull/17844/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17844&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325860 Stats: 135 lines in 10 files changed: 28 ins; 54 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/17844.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17844/head:pull/17844 PR: https://git.openjdk.org/jdk/pull/17844 From mgronlun at openjdk.org Wed Feb 14 14:13:08 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 14 Feb 2024 14:13:08 GMT Subject: Integrated: 8323883: JFR AssertionError: Missing object ID 15101 In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 13:46:40 GMT, Markus Gr?nlund wrote: > Greetings, > > The following adjustments fix the intermittent issues with incomplete tag sets for a chunk. The situations are pretty subtle: > > 1. A situation can occur where an event is emitted during the event instrumentation callback as part of JVMTI Retransform (ErrorThrownEvent). A stack trace is captured that marks, or "tags", the existing method(s) of the klass (i.e. when the scratch class is instrumented). But after the instrumentation call returns, the set of methods of the klass is exchanged from the "old" methods (now marked) , to the new set of methods (from the scratch class, not marked). This means the mark/tag is lost for a method. Therefore, method tags must be transferred when exchanging methods during JVMTI redefine / retransform. > 2. OldObjectSample events are emitted at the end of a recording. As part of writing the events, several checkpoint events are also created and enqueued. But these checkpoints are incomplete standalone because they need to be complemented with a typeset checkpoint, which happens just after, as part of the rotation. But flush() can occur concurrently with OldObjectSample emit, and can, therefore, serialize these checkpoints to a segment before the complementary typeset checkpoint has been created. There needs to be mutual exclusion between OldObjectSample emit() and flush(), now provided by the JfrRotationLock. > 3. The set of artefacts captured during class unloading is incomplete because it respects already serialized artefacts. However, because class unloading typesets are linked to OldObjectSamples and DeprecatedInvocation events, which survive chunk boundaries, these unloading typesets can be serialized in later chunks. If the unloading set is incomplete (not transitive), there will be missing constants. Hence, class unloading typesets require serialization of the entire transitive set of unloading artefacts, even if they have already been serialized to the current chunk. > > As part of fixing these issues, the disabled assert is also reactivated. > > Testing: jdk_jfr, stress testing, tier 1-6 > > Thanks > Markus This pull request has now been integrated. Changeset: 737b4c51 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/737b4c515e082239579369d9806307b9f16c4816 Stats: 166 lines in 15 files changed: 81 ins; 48 del; 37 mod 8323883: JFR AssertionError: Missing object ID 15101 Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/17771 From mgronlun at openjdk.org Wed Feb 14 14:13:07 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 14 Feb 2024 14:13:07 GMT Subject: RFR: 8323883: JFR AssertionError: Missing object ID 15101 In-Reply-To: <1tI2HvKcvzBT4aI5B-aebO6o2_BWkOKeHoNNwcRug6E=.21d5452a-c5f1-4afc-afc2-c589d2c444f0@github.com> References: <1tI2HvKcvzBT4aI5B-aebO6o2_BWkOKeHoNNwcRug6E=.21d5452a-c5f1-4afc-afc2-c589d2c444f0@github.com> Message-ID: On Fri, 9 Feb 2024 15:51:32 GMT, Erik Gahlin wrote: >> Greetings, >> >> The following adjustments fix the intermittent issues with incomplete tag sets for a chunk. The situations are pretty subtle: >> >> 1. A situation can occur where an event is emitted during the event instrumentation callback as part of JVMTI Retransform (ErrorThrownEvent). A stack trace is captured that marks, or "tags", the existing method(s) of the klass (i.e. when the scratch class is instrumented). But after the instrumentation call returns, the set of methods of the klass is exchanged from the "old" methods (now marked) , to the new set of methods (from the scratch class, not marked). This means the mark/tag is lost for a method. Therefore, method tags must be transferred when exchanging methods during JVMTI redefine / retransform. >> 2. OldObjectSample events are emitted at the end of a recording. As part of writing the events, several checkpoint events are also created and enqueued. But these checkpoints are incomplete standalone because they need to be complemented with a typeset checkpoint, which happens just after, as part of the rotation. But flush() can occur concurrently with OldObjectSample emit, and can, therefore, serialize these checkpoints to a segment before the complementary typeset checkpoint has been created. There needs to be mutual exclusion between OldObjectSample emit() and flush(), now provided by the JfrRotationLock. >> 3. The set of artefacts captured during class unloading is incomplete because it respects already serialized artefacts. However, because class unloading typesets are linked to OldObjectSamples and DeprecatedInvocation events, which survive chunk boundaries, these unloading typesets can be serialized in later chunks. If the unloading set is incomplete (not transitive), there will be missing constants. Hence, class unloading typesets require serialization of the entire transitive set of unloading artefacts, even if they have already been serialized to the current chunk. >> >> As part of fixing these issues, the disabled assert is also reactivated. >> >> Testing: jdk_jfr, stress testing, tier 1-6 >> >> Thanks >> Markus > > Nice work! > > Let's hope this will be the last "missing object ID" bug to make it into main-line. Thanks @egahlin for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17771#issuecomment-1943842563 From sspitsyn at openjdk.org Wed Feb 14 15:25:33 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Feb 2024 15:25:33 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v8] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: added assert to get_pending_threads; added suggested coverage to test objmonusage003 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/674da98c..1ab5b349 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=06-07 Stats: 132 lines in 2 files changed: 106 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From sspitsyn at openjdk.org Wed Feb 14 15:25:35 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Feb 2024 15:25:35 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:05:38 GMT, David Holmes wrote: >> Serguei Spitsyn 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 >> - review: thread in notify waiter list can't be BLOCKED >> - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage > > Based on Dan's analysis I would have to go back and redo the complete analysis for myself. :( I think the only way to make sense of this is to actually set up scenarios where we have different threads contending on entry, different threads waiting and different threads re-entering after being notified, and see what values actually get returned in each case. > > I think the `pending_current_monitor` issue may be a distinct/different issue. I can easily imagine that this was overlooked when we introduced the "wait morphing" rather than have the notified/timed-out/interrupted waiters actually place themselves on the entry queue. >From @dholmes-ora : > If you don't check all the zero/non-zero permutations for the three counts of interest then you don't know that you are combining them the right way to give the two counts reported by the API. Okay, thanks. I've added the suggested test cases to the `nsk/jvmti/GetObjectMonitorUsage/objmonusage003`. One of the testcases is covered by the `nsk/jvmti/GetObjectMonitorUsage/objmonusage001`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944052748 From kbarrett at openjdk.org Wed Feb 14 16:07:15 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 Feb 2024 16:07:15 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 11:05:30 GMT, Magnus Ihse Bursie wrote: >> There are several places in hotspot where an internal function should have been declared static, but isn't. >> >> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: >> a) is declared static, or >> b) has a declaration before its definition. >> >> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. >> >> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. >> >> This is the first part of addressing these issues, where all places that are trivially missing static are fixed. >> >> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. >> >> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not disc... > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert spurious changes in non-modified file > - Fix indentation issues Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1880692930 From ihse at openjdk.org Wed Feb 14 16:32:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 Feb 2024 16:32:59 GMT Subject: Integrated: 8252136: Several methods in hotspot are missing "static" In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie wrote: > There are several places in hotspot where an internal function should have been declared static, but isn't. > > These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either: > a) is declared static, or > b) has a declaration before its definition. > > The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining. > > This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed. > > This is the first part of addressing these issues, where all places that are trivially missing static are fixed. > > I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR. > > When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi... This pull request has now been integrated. Changeset: 09d49366 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/09d4936657a0bdc122a4ab80735bd9c8c109839c Stats: 228 lines in 71 files changed: 8 ins; 1 del; 219 mod 8252136: Several methods in hotspot are missing "static" Reviewed-by: coleenp, stefank, kvn, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/17806 From ayang at openjdk.org Wed Feb 14 17:39:13 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 14 Feb 2024 17:39:13 GMT Subject: RFR: 8325860: Serial: Move Generation.java to serial folder [v2] In-Reply-To: References: Message-ID: > Relocate `Generation.java` to mirror the structure in hotspot. Also, specialize the logic to two concrete generations. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: sa-move-generation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17844/files - new: https://git.openjdk.org/jdk/pull/17844/files/05a6373a..c287817f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17844&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17844&range=00-01 Stats: 6617 lines in 129 files changed: 1663 ins; 3563 del; 1391 mod Patch: https://git.openjdk.org/jdk/pull/17844.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17844/head:pull/17844 PR: https://git.openjdk.org/jdk/pull/17844 From dcubed at openjdk.org Wed Feb 14 18:36:04 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 14 Feb 2024 18:36:04 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: On Wed, 14 Feb 2024 11:56:27 GMT, Serguei Spitsyn wrote: > Thanks, Dan. I've pushed the suggested test changes but refactored them a little bit. You are welcome. I presume the revised test passes with your fix in place. I made the test changes on a baseline repo and not a repo that had your changes which is why I had temporary debug flags in the test.. Also, do you agree with my test assertion comments in the verification point comments? Am I properly understanding how we are changing this API? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944382731 From duke at openjdk.org Wed Feb 14 18:47:58 2024 From: duke at openjdk.org (duke) Date: Wed, 14 Feb 2024 18:47:58 GMT Subject: Withdrawn: 8321971: Improve the user name detection logic in perfMemory get_user_name_slow In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 10:13:51 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to improve the code in `get_user_name_slow` function, which is used to identify the target JVM owner's user name? This addresses https://bugs.openjdk.org/browse/JDK-8321971. > > As noted in that JBS issue, in its current form, the nested loop ends up iterating over the directory contents of `hsperfdata_xxx` directory and then for each iteration it checks if the name of the entry matches the pid. This iteration shouldn't be needed and instead one could look for a file named `` within that directory. > > No new test has been added, given the nature of this change. Existing tier1, tier2, tier3 and svc_tools tests pass with this change on Linux, Windows and macosx. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17104 From duke at openjdk.org Wed Feb 14 18:57:02 2024 From: duke at openjdk.org (duke) Date: Wed, 14 Feb 2024 18:57:02 GMT Subject: Withdrawn: 8319115: GrowableArray: Do not initialize up to capacity In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 07:56:04 GMT, Emanuel Peter wrote: > Before this patch, we always initialized the GrowableArray up to its `capacity`, and not just up to `length`. This is problematic for a few reasons: > > - It is not expected. `std::vector` also only initializes the elements up to its size, and not to capacity. > - It requires a default-constructor for the element type. And the default-constructor is then used to fill in the elements between length and capacity. If the elements do any allocation themselves, then this is a waste of resources. > - The implementation also required the copy-assignment-operator for the element type. This is a lesser restriction. But the copy-assignment-operator was used in cases like `append` (where placement copy-construct would be expected), and not just in true assignment kinds of cases like `at_put`. > > For this reason, I reworked a lot of the methods to ensure that only the "slots" up to `length` are ever initialized, and the space between `length` and `capacity` is always garbage. > > ----- > > Also, before this patch, one can CHeap allocate both with `GrowableArray` and `GrowableArrayCHeap`. This is unnecessary. It required more complex verification in `GrowableArray` to deal with all cases. And `GrowableArrayCHeap` is already explicitly a smaller object, and should hence be preferred. Hence I changed all CHeap allocating cases of `GrowableArray` to `GrowableArrayCHeap`. This also allows for a clear separation: > - `GrowableArray` only deals with arena / resource area allocation. These are arrays that are regularly abandoned at the end of their use, rather than deleted or even cleared. > - `GrowableArrayCHeap` only deals with CHeap allocated memory. We expect that the destructor for it is called eventually, either when it goes out of scope or when `delete` is explicitly called. We expect that the elements could be allocating resources internally, and hence rely on the destructors for the elements being called, which may free up those internally allocated resources. > > Therefore, we now only allow `GrowableArrayCHeap` to have element types with non-trivial destructors, but `GrowableArray` checks that element types do not have non-trivial destructors (since it is common practice to just abandon arena / resource area allocated arrays, rather than calling the destructor or clearing the array, which also destructs all elements). This more clearly separates the two worlds: clean-up your own mess (CHeap) vs abandon your mess (arena / resource area). > > ----- > > I also completely refactored and improved ... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16918 From cjplummer at openjdk.org Wed Feb 14 20:04:03 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Feb 2024 20:04:03 GMT Subject: RFR: 8325860: Serial: Move Generation.java to serial folder [v2] In-Reply-To: References: Message-ID: <4UBsBp9PobMBQDQecs2x1fpx39cKhXb6Khuq30m0cb4=.b40f26da-efc3-4639-9c11-d8c49507361f@github.com> On Wed, 14 Feb 2024 17:39:13 GMT, Albert Mingkun Yang wrote: >> Relocate `Generation.java` to mirror the structure in hotspot. Also, specialize the logic to two concrete generations. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > sa-move-generation TestUniverse.java needs a copyright update. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/Generation.java line 112: > 110: public boolean isIn(Address p) { > 111: GenerationIsInClosure blk = new GenerationIsInClosure(p); > 112: spaceIterate(blk); It looks like spaceIterate() is no longer needed. ------------- Changes requested by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17844#pullrequestreview-1881158055 PR Review Comment: https://git.openjdk.org/jdk/pull/17844#discussion_r1489990254 From cjplummer at openjdk.org Wed Feb 14 20:10:05 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Feb 2024 20:10:05 GMT Subject: RFR: 8325860: Serial: Move Generation.java to serial folder [v2] In-Reply-To: <4UBsBp9PobMBQDQecs2x1fpx39cKhXb6Khuq30m0cb4=.b40f26da-efc3-4639-9c11-d8c49507361f@github.com> References: <4UBsBp9PobMBQDQecs2x1fpx39cKhXb6Khuq30m0cb4=.b40f26da-efc3-4639-9c11-d8c49507361f@github.com> Message-ID: <_PaF4vhT2wNm8uY28jIZoQFobXGrjgD_PaB7Qbrecn8=.38b5959c-2c6a-4ac9-868c-41eab73ff8ae@github.com> On Wed, 14 Feb 2024 19:57:00 GMT, Chris Plummer wrote: >> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> sa-move-generation > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/Generation.java line 112: > >> 110: public boolean isIn(Address p) { >> 111: GenerationIsInClosure blk = new GenerationIsInClosure(p); >> 112: spaceIterate(blk); > > It looks like spaceIterate() is no longer needed. And I think you can get rid of GenerationIsInClosure also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17844#discussion_r1490000450 From ayang at openjdk.org Wed Feb 14 20:17:21 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 14 Feb 2024 20:17:21 GMT Subject: RFR: 8325860: Serial: Move Generation.java to serial folder [v3] In-Reply-To: References: Message-ID: > Relocate `Generation.java` to mirror the structure in hotspot. Also, specialize the logic to two concrete generations. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request incrementally with three additional commits since the last revision: - remove-space-ite - remove - year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17844/files - new: https://git.openjdk.org/jdk/pull/17844/files/c287817f..e6214e06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17844&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17844&range=01-02 Stats: 67 lines in 5 files changed: 0 ins; 66 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17844.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17844/head:pull/17844 PR: https://git.openjdk.org/jdk/pull/17844 From sspitsyn at openjdk.org Wed Feb 14 20:35:05 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Feb 2024 20:35:05 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> Message-ID: On Wed, 14 Feb 2024 18:33:19 GMT, Daniel D. Daugherty wrote: >>> When you get the chance, can you checkout these possible >> changes for the objmonusage001 test? >> >> Thanks, Dan. I've pushed the suggested test changes but refactored them a little bit. > >> Thanks, Dan. I've pushed the suggested test changes but refactored them a little bit. > > You are welcome. I presume the revised test passes with your fix in place. I made the > test changes on a baseline repo and not a repo that had your changes which is why I > had temporary debug flags in the test.. > > Also, do you agree with my test assertion comments in the verification point comments? > Am I properly understanding how we are changing this API? >From @dcubed-ojdk : > Also, do you agree with my test assertion comments in the verification point comments? > Am I properly understanding how we are changing this API? Yes, I agree. All looks right to me. Q: Do you want to keep the `CHECK_FOR_BAD_RESULTS` mode or it can be removed after the failing output was verified? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944545272 From cjplummer at openjdk.org Wed Feb 14 20:35:06 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Feb 2024 20:35:06 GMT Subject: RFR: 8325860: Serial: Move Generation.java to serial folder [v3] In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 20:17:21 GMT, Albert Mingkun Yang wrote: >> Relocate `Generation.java` to mirror the structure in hotspot. Also, specialize the logic to two concrete generations. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with three additional commits since the last revision: > > - remove-space-ite > - remove > - year Looks good. Thanks for the cleanup. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17844#pullrequestreview-1881261325 From dcubed at openjdk.org Wed Feb 14 21:17:03 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 14 Feb 2024 21:17:03 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v8] In-Reply-To: References: Message-ID: <225C3AcEAOR7Zd--eHOBiqFHVv6h3Vpqet9TvXM1t08=.a086aa88-bb89-4d2d-9186-9a22eab00db4@github.com> On Wed, 14 Feb 2024 15:25:33 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: added assert to get_pending_threads; added suggested coverage to test objmonusage003 CHECK_FOR_BAD_RESULTS and ADD_DELAYS_FOR_RACES flags and their associated code paths are for temporary debugging only. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944611040 From amenkov at openjdk.org Wed Feb 14 22:26:14 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 14 Feb 2024 22:26:14 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps Message-ID: The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) Testing: tier1, tier2, tier5-svc ------------- Commit messages: - jcheck - fix Changes: https://git.openjdk.org/jdk/pull/17855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17855&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8176520 Stats: 175 lines in 6 files changed: 141 ins; 21 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/17855.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17855/head:pull/17855 PR: https://git.openjdk.org/jdk/pull/17855 From amenkov at openjdk.org Thu Feb 15 02:45:26 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Feb 2024 02:45:26 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: > The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) > > Testing: tier1, tier2, tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: test bug id ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17855/files - new: https://git.openjdk.org/jdk/pull/17855/files/814cef3a..abba6396 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17855&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17855&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17855.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17855/head:pull/17855 PR: https://git.openjdk.org/jdk/pull/17855 From kbarrett at openjdk.org Thu Feb 15 03:08:05 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 15 Feb 2024 03:08:05 GMT Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 10:29:48 GMT, Magnus Ihse Bursie wrote: >> src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp line 202: >> >>> 200: static RootDescriptionInfo* root_infos = nullptr; >>> 201: >>> 202: static int __write_sample_info__(JfrCheckpointWriter* writer, const void* si) { >> >> pre-existing: all these names starting with underscores are technically reserved names - C++14 17.6.4.3.2. >> Shouldn't be changed as part of this PR, but perhaps there should be a bug report? Don't know if anyone >> would ever get around to doing anything about it though. > > Please feel free to open a bug report. ? > > Unless there is a warning flag to avoid creating reserved names (is there?), it is more of a matter of coding style on the part of Hotspot, and that is basically where I draw the line of my meddling with Hotspot. :) I just discovered that Clang 13 added `-Wreserved-identifier`. There's also an open gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 And a discussion of the "chattiness" of the feature: https://github.com/llvm/llvm-project/issues/57913#issuecomment-1255493025 Probably there's not much appetite for this sort of thing, and I shouldn't have brought it up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1490315316 From cjplummer at openjdk.org Thu Feb 15 04:07:02 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Feb 2024 04:07:02 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 02:45:26 GMT, Alex Menkov wrote: >> The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) >> >> Testing: tier1, tier2, tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > test bug id The test is odd in a couple of ways. The first is it's in the SA test directory, yet is also meant as a VM heap dump test. If someone were to make changes to the VM heapdump code and run the VM heapdump tests, this test would not get run. The other oddity is that it is not testing if the hprof file is correct. It is instead testing if SA and the VM produce the same result. Although that is a valid thing to test for, it seems correctness should also be tested for. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1945328399 From mdoerr at openjdk.org Thu Feb 15 04:39:06 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 15 Feb 2024 04:39:06 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13] In-Reply-To: <8OXB2hSdtUljShW9BxphktBQGlsmjGATVODGUxeKlho=.7c7f3ee8-bdaf-4723-a8e7-f9829bf3ae41@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <8OXB2hSdtUljShW9BxphktBQGlsmjGATVODGUxeKlho=.7c7f3ee8-bdaf-4723-a8e7-f9829bf3ae41@github.com> Message-ID: On Thu, 1 Feb 2024 10:31:14 GMT, Thomas Stuefe wrote: >> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: >> >> spelling > > I'm busy with FOSDEM this week and probably next. Will look at this end of next week or the week after. @tstuefe, @offamitkumar: You had requested changes. Should we wait for your feedback regarding the latest version? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1945348564 From amitkumar at openjdk.org Thu Feb 15 04:44:58 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 15 Feb 2024 04:44:58 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Remove not matched trailing whitespaces Maybe the copyright year could be updated. Nothing else on my side. ------------- Marked as reviewed by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1881747083 From dholmes at openjdk.org Thu Feb 15 07:12:04 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Feb 2024 07:12:04 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v5] In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 12:16:38 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/threads.cpp line 1200: >> >>> 1198: if (pending == monitor || >>> 1199: (waiting == monitor && JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER == >>> 1200: java_lang_Thread::get_thread_status(p->vthread_or_thread())) >> >> This code seems extremely racy. Is there anything that is stopping the target thread from running while we attempt this inspection of the oop state? If it was waiting and was interrupted or timed-out then we could mistakenly think it was still pending entry to this monitor when in fact it is not. >> It is also a shame that we have to reach up into the oop thread state to figure out if if it is blocked on re-entry ... > > The function `get_pending_threads()` is executed only by the VM_GetObjectMonitorUsage operation. > I've added this assert there: > `assert(Thread::current()->is_VM_thread(), "Must be the VM thread");` > Does it address your concern? Yes thanks. Didn't realize we were in a safepoint VM op. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1490510763 From stuefe at openjdk.org Thu Feb 15 08:18:09 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 15 Feb 2024 08:18:09 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Remove not matched trailing whitespaces Hi, some remarks: - there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1. - I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines - Please use os::strdup. - Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future) Thank you, Thomas ------------- Changes requested by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1882051726 From sspitsyn at openjdk.org Thu Feb 15 08:53:24 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Feb 2024 08:53:24 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code Message-ID: This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` This addresses a category of NULL uses that wasn't dealt with by: [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). Testing: - TBD: run mach5 tiers1-3 ------------- Commit messages: - 8324680: Replace NULL with nullptr in JVMTI generated code Changes: https://git.openjdk.org/jdk/pull/17866/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17866&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324680 Stats: 110 lines in 5 files changed: 0 ins; 0 del; 110 mod Patch: https://git.openjdk.org/jdk/pull/17866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17866/head:pull/17866 PR: https://git.openjdk.org/jdk/pull/17866 From tschatzl at openjdk.org Thu Feb 15 09:24:03 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 Feb 2024 09:24:03 GMT Subject: RFR: 8325860: Serial: Move Generation.java to serial folder [v3] In-Reply-To: References: Message-ID: <2X1nlm3Doq-Owl3bbilHzgZfdQX00X0LkIcZMHefpCg=.d83069e1-7b52-44fe-95cb-334c97c2bbd8@github.com> On Wed, 14 Feb 2024 20:17:21 GMT, Albert Mingkun Yang wrote: >> Relocate `Generation.java` to mirror the structure in hotspot. Also, specialize the logic to two concrete generations. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with three additional commits since the last revision: > > - remove-space-ite > - remove > - year Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17844#pullrequestreview-1882199189 From ayang at openjdk.org Thu Feb 15 10:23:07 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 15 Feb 2024 10:23:07 GMT Subject: RFR: 8325860: Serial: Move Generation.java to serial folder [v3] In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 20:17:21 GMT, Albert Mingkun Yang wrote: >> Relocate `Generation.java` to mirror the structure in hotspot. Also, specialize the logic to two concrete generations. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with three additional commits since the last revision: > > - remove-space-ite > - remove > - year Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17844#issuecomment-1945771139 From ayang at openjdk.org Thu Feb 15 10:23:08 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 15 Feb 2024 10:23:08 GMT Subject: Integrated: 8325860: Serial: Move Generation.java to serial folder In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 13:15:27 GMT, Albert Mingkun Yang wrote: > Relocate `Generation.java` to mirror the structure in hotspot. Also, specialize the logic to two concrete generations. > > Test: tier1-3 This pull request has now been integrated. Changeset: 2b1a8400 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/2b1a8400023d4fdbe253c44d68db630864ae5e55 Stats: 471 lines in 13 files changed: 160 ins; 252 del; 59 mod 8325860: Serial: Move Generation.java to serial folder Reviewed-by: cjplummer, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/17844 From sspitsyn at openjdk.org Thu Feb 15 11:49:07 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Feb 2024 11:49:07 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v4] In-Reply-To: <2iPk6kfykXqnv2hTa6GyvRTcI71om0C6X3Z0bZZMaOM=.1b6f9718-dc85-4b09-8cb1-5d53f1cb0a36@github.com> References: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com> <2iPk6kfykXqnv2hTa6GyvRTcI71om0C6X3Z0bZZMaOM=.1b6f9718-dc85-4b09-8cb1-5d53f1cb0a36@github.com> Message-ID: On Wed, 14 Feb 2024 01:52:16 GMT, David Holmes wrote: >> Thank you for the comment, David. >> Now the test checks: >> - the threads waiting to enter the monitor are returned correctly with all permutations of threads waiting to be notified and threads waiting to re-enter the monitor >> Initially, there are 4 threads waiting to be notified and zero threads waiting to re-enter the monitor. >> They are notified one by with the subsequent checks, so all the pairs are checked ``: `<0,4>, <1,3>, <2,2>, <3,1>, <4,0>` >> >> I'm not sure why do you think all permutations covering zero and non-zero for each one are needed. >> At least, it looks like an overkill to me. But if you still think it is really important then I can add cases with zero threads waiting to enter the monitor with the same permutations of threads waiting to be notified and threads re-entering the monitor. > > If you don't check all the zero/non-zero permutations for the three counts of interest then you don't know that you are combining them the right way to give the two counts reported by the API. > Note that checking "all the pairs" is not really necessary as all non-zero values fall in the same equivalence class for testing purposes. The last suggestion has been addressed by adding missing test cases to the `nsk/jvmti/GetObjectMonitorUsage/objmonusage003` test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1490889210 From ihse at openjdk.org Thu Feb 15 12:29:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 15 Feb 2024 12:29:23 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck Message-ID: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. ------------- Commit messages: - 8325950: Make sure all files in the JDK pass jcheck Changes: https://git.openjdk.org/jdk/pull/17871/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17871&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325950 Stats: 113 lines in 38 files changed: 0 ins; 10 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/17871.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17871/head:pull/17871 PR: https://git.openjdk.org/jdk/pull/17871 From ihse at openjdk.org Thu Feb 15 12:29:24 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 15 Feb 2024 12:29:24 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote: > Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). > > I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. Some general remarks: The problems in .m4 files where not properly detected and fixed when I added .m4 to the list of checked files. The properties files were recently checked by me, so these suprrised me. It turned out I had misunderstood the jcheck criteria: I thought only leading tabs were disallowed, but it is actually tabs anywhere in the file that are banned. In general, I have replaced tab characters with spaces aligning to tab stops at 8 characters distance. I'll leave some remarks for individual files. src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties line 10: > 8: java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject > 9: > 10: # RemoteToAttrs: Turn RMI/JRMP and RMI/IIOP object into javaMarshalledObject or I adjusted this tab stop (with one space) so it aligned properly with the line above; I think that was the intention. src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties line 41: > 39: jdk.internal.ref.Cleaner=Use java.lang.ref.PhantomReference @since 1.2 or java.lang.ref.Cleaner @since 9 > 40: sun.awt.CausedFocusEvent=Use java.awt.event.FocusEvent::getCause @since 9 > 41: sun.font.FontUtilities=See java.awt.Font.textRequiresLayout @since 9 This tab just looked out of place, so I replaced it with a space. (Rhyming not intentional...) test/hotspot/jtreg/containers/docker/JfrReporter.java line 52: > 50: } > 51: } > 52: } I'm not sure how a Java file ever got into the code base with trailing spaces, but a guess is that there have been a bug in jcheck that did not properly check for trailing whitespace at the end of the file, or something like that. test/jdk/java/util/Currency/currency.properties line 18: > 16: SB=EUR,111,2, 2099-01-01T00:00:00 > 17: US=euR,978,2,2001-01-01T00:00:00 > 18: ZZ = ZZZ , 999 , 3 This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17871#issuecomment-1945992837 PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931378 PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931979 PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490933432 PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490934063 From shade at openjdk.org Thu Feb 15 13:19:02 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 15 Feb 2024 13:19:02 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 02:45:26 GMT, Alex Menkov wrote: >> The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) >> >> Testing: tier1, tier2, tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > test bug id When I proposed this change 10 years ago, there was a push back: https://bugs.openjdk.org/browse/JDK-8005604. Is it resolved now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1946077314 From erikj at openjdk.org Thu Feb 15 14:05:12 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 15 Feb 2024 14:05:12 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 12:26:11 GMT, Magnus Ihse Bursie wrote: >> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). >> >> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. > > test/jdk/java/util/Currency/currency.properties line 18: > >> 16: SB=EUR,111,2, 2099-01-01T00:00:00 >> 17: US=euR,978,2,2001-01-01T00:00:00 >> 18: ZZ = ZZZ , 999 , 3 > > This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker. This looks weird indeed. Luckily it's just test code. Did you run the test after this change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491056108 From ihse at openjdk.org Thu Feb 15 15:50:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 15 Feb 2024 15:50:57 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson wrote: >> test/jdk/java/util/Currency/currency.properties line 18: >> >>> 16: SB=EUR,111,2, 2099-01-01T00:00:00 >>> 17: US=euR,978,2,2001-01-01T00:00:00 >>> 18: ZZ = ZZZ , 999 , 3 >> >> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker. > > This looks weird indeed. Luckily it's just test code. Did you run the test after this change? All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491227492 From naoto at openjdk.org Thu Feb 15 17:12:55 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Feb 2024 17:12:55 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 15:48:38 GMT, Magnus Ihse Bursie wrote: >> This looks weird indeed. Luckily it's just test code. Did you run the test after this change? > > All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test. Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491352359 From angorya at openjdk.org Thu Feb 15 17:31:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Feb 2024 17:31:56 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 17:09:17 GMT, Naoto Sato wrote: >> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test. > > Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`) `\u000b` is VT (vertical tab) `\u0009` or `\t` perhaps? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491375928 From sroy at openjdk.org Thu Feb 15 17:53:01 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 15 Feb 2024 17:53:01 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com> On Thu, 15 Feb 2024 08:15:16 GMT, Thomas Stuefe wrote: > Hi, > > some remarks: > > * there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1. > * I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines > * Please use os::strdup. > * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future) > > Thank you, Thomas Sure working on them. May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1946756694 From naoto at openjdk.org Thu Feb 15 17:55:58 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Feb 2024 17:55:58 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 17:28:52 GMT, Andy Goryachev wrote: >> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`) > > `\u000b` is VT (vertical tab) > `\u0009` or `\t` perhaps? Right. `\t` is better to avoid such a mistake. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491403426 From sspitsyn at openjdk.org Thu Feb 15 19:55:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Feb 2024 19:55:08 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v9] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/1ab5b349..c8b8e376 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=07-08 Stats: 25 lines in 2 files changed: 0 ins; 13 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From sspitsyn at openjdk.org Thu Feb 15 20:09:54 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Feb 2024 20:09:54 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v9] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 19:55:08 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001 I've pushed an update that includes: - added minor spec clarification for JDWP `ObjectReference.MonitorInfo` command (please, see the CSR) - removed the CHECK_FOR_BAD_RESULTS debugging mode from the test: `nsk/jvmti/GetObjectMonitorUsage/objmonusage001` ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1947208935 From cjplummer at openjdk.org Thu Feb 15 21:03:54 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Feb 2024 21:03:54 GMT Subject: RFR: 8316451: 6 java/lang/instrument/PremainClass tests ignore VM flags In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 23:30:01 GMT, Leonid Mesnik wrote: > Tests updated to use jtreg vm flags. > Tested by running tests with different flags and tier1. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17781#pullrequestreview-1883870729 From sspitsyn at openjdk.org Thu Feb 15 22:27:53 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Feb 2024 22:27:53 GMT Subject: RFR: 8316451: 6 java/lang/instrument/PremainClass tests ignore VM flags In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 23:30:01 GMT, Leonid Mesnik wrote: > Tests updated to use jtreg vm flags. > Tested by running tests with different flags and tier1. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17781#pullrequestreview-1883994215 From prr at openjdk.org Thu Feb 15 22:40:56 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Feb 2024 22:40:56 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote: > Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). > > I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. desktop changes look fine to me. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884009342 From lmesnik at openjdk.org Thu Feb 15 22:52:58 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Feb 2024 22:52:58 GMT Subject: Integrated: 8316451: 6 java/lang/instrument/PremainClass tests ignore VM flags In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 23:30:01 GMT, Leonid Mesnik wrote: > Tests updated to use jtreg vm flags. > Tested by running tests with different flags and tier1. This pull request has now been integrated. Changeset: 9029bf64 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/9029bf644e238a504e1f114a73edf5760d19980b Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod 8316451: 6 java/lang/instrument/PremainClass tests ignore VM flags Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/17781 From amenkov at openjdk.org Fri Feb 16 01:25:53 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Feb 2024 01:25:53 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 13:15:51 GMT, Aleksey Shipilev wrote: > When I proposed this change 10 years ago, there was a push back: https://bugs.openjdk.org/browse/JDK-8005604. > > Is it resolved now? Thank you for the link @shipilev. I've read the discussion, my understanding that main concern was the change can break external hprof parsers. First of all, the change does not change hprof format. "Instance size" field in HPROF_GC_CLASS_DUMP recors is not required for parsing classes or objects, it's needed only for analysis (search for leak suspects, etc.) And "actual" size of objects in the heap is quite important for the analysis. I looked at the code of 2 popular open-source hprof parsers/analyzers: VisualVM and Eclipse Memory Analyzer. Both do not rely on the class instance size value from hprof file, but try to calculate (guess) it using knowledge about JVM internals. Note also that this enhancement request came from VisualVM maintainer. So I think it's a desired change with low risk of affecting hprof consumers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1947598443 From wetmore at openjdk.org Fri Feb 16 01:44:57 2024 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 Feb 2024 01:44:57 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote: > Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). > > I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. security properties looks ok. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884183930 From amenkov at openjdk.org Fri Feb 16 01:54:55 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Feb 2024 01:54:55 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 04:04:19 GMT, Chris Plummer wrote: > The test is odd in a couple of ways. The first is it's in the SA test directory, yet is also meant as a VM heap dump test. If someone were to make changes to the VM heapdump code and run the VM heapdump tests, this test would not get run. The other oddity is that it is not testing if the hprof file is correct. It is instead testing if SA and the VM produce the same result. Although that is a valid thing to test for, it seems correctness should also be tested for. Ok, then I think the test should be split on 2 tests One in test/hotspot/jtreg/serviceability/HeapDump to test VM dumper only (verifies correctness, checks that instance size for all instance klasses >0); Another one in the SA test directory, tests VM and SA heap dumpers consistency (equal instance size for the same classes) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1947637329 From amenkov at openjdk.org Fri Feb 16 02:39:53 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Feb 2024 02:39:53 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote: > This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. > > The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` > > This addresses a category of NULL uses that wasn't dealt with by: > [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). > > Testing: > - TBD: run mach5 tiers1-3 Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17866#pullrequestreview-1884223391 From stuefe at openjdk.org Fri Feb 16 05:27:58 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 16 Feb 2024 05:27:58 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com> Message-ID: On Thu, 15 Feb 2024 17:50:23 GMT, Suchismith Roy wrote: > > Hi, > > some remarks: > > > > * there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1. > > * I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines > > * Please use os::strdup. > > * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future) > > > > Thank you, Thomas > > Sure working on them. May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ? I don't understand the question, sorry. What I mean is when the first dlopen fails AND its error indicates the shared library had been missing, only then attempt the *.a fallback. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1947780121 From sspitsyn at openjdk.org Fri Feb 16 06:12:54 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Feb 2024 06:12:54 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote: > This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. > > The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` > > This addresses a category of NULL uses that wasn't dealt with by: > [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). > > Testing: > - TBD: run mach5 tiers1-3 Thank you for review, Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1947814286 From dholmes at openjdk.org Fri Feb 16 06:19:54 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Feb 2024 06:19:54 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v9] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 19:55:08 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001 Thanks for the test updates. A couple of other queries. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1496: > 1494: nWant = wantList->length(); > 1495: > 1496: if (mon != nullptr) { Shouldn't the call to `get_pending_threads` only happen if `mon != nullptr`? Otherwise the `wantList` has to be empty. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1500: > 1498: for (int i = 0; i < nWait; i++) { > 1499: if (waiter == nullptr || (i != 0 && waiter == mon->first_waiter())) { > 1500: // robustness: the waiting list has gotten smaller We are at a safepoint so I don't see how the wait list can shrink. I initially thought perhaps a waiter could timeout, but the code that does the timed park is wrapped in ` ThreadBlockInVMPreprocess` which will block at a safepoint if one is active. ------------- PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1884365884 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1491992136 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1491997307 From sroy at openjdk.org Fri Feb 16 12:27:58 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Fri, 16 Feb 2024 12:27:58 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com> Message-ID: On Fri, 16 Feb 2024 05:25:44 GMT, Thomas Stuefe wrote: > > > Hi, > > > some remarks: > > > > > > * there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1. > > > * I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines > > > * Please use os::strdup. > > > * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future) > > > > > > Thank you, Thomas > > > > > > Sure working on them. May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ? > > I don't understand the question, sorry. > > What I mean is when the first dlopen fails AND its error indicates the shared library had been missing, only then attempt the *.a fallback. I see. I think i was referred to the init routine in the link. So you mean based on the errors inside dll_load_library, we set the errno to appropriate Error and then check for that before using the fallback , is that correct ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1948295997 From ihse at openjdk.org Fri Feb 16 12:43:25 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 16 Feb 2024 12:43:25 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2] In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: > Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). > > I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Replace spaces with \t in test properties file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17871/files - new: https://git.openjdk.org/jdk/pull/17871/files/3faa912e..e1c9c0f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17871&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17871&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17871.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17871/head:pull/17871 PR: https://git.openjdk.org/jdk/pull/17871 From ihse at openjdk.org Fri Feb 16 12:43:25 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 16 Feb 2024 12:43:25 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2] In-Reply-To: References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato wrote: >> `\u000b` is VT (vertical tab) >> `\u0009` or `\t` perhaps? > > Right. `\t` is better to avoid such a mistake. Ok, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403 From stuefe at openjdk.org Fri Feb 16 12:53:01 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 16 Feb 2024 12:53:01 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com> Message-ID: On Fri, 16 Feb 2024 12:25:39 GMT, Suchismith Roy wrote: > > > > Hi, > > > > some remarks: > > > > > > > > * there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1. > > > > * I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines > > > > * Please use os::strdup. > > > > * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future) > > > > > > > > Thank you, Thomas > > > > > > > > > Sure working on them. May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ? > > > > > > I don't understand the question, sorry. > > What I mean is when the first dlopen fails AND its error indicates the shared library had been missing, only then attempt the *.a fallback. > > I see. I think i was referred to the init routine in the link. Ah, okay. No, IBMs dlopen page for AIX refers to this page for the list of possible error codes; I assume dlopen just uses these functions under the hood. > So you mean based on the errors inside dll_load_library, we set the errno to appropriate Error and then check for that before using the fallback , is that correct ? No. I mean distinguish whether dlopen fails because it could not find the file (a valid reason to retry with *.a) or failed for another reason (which would not be a valid reason to retry with *.a). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1948333340 From coleenp at openjdk.org Fri Feb 16 12:55:54 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 16 Feb 2024 12:55:54 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote: > This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. > > The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` > > This addresses a category of NULL uses that wasn't dealt with by: > [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). > > Testing: > - TBD: run mach5 tiers1-3 Looks good, thanks for fixing this. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17866#pullrequestreview-1885068558 From erikj at openjdk.org Fri Feb 16 13:39:56 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 16 Feb 2024 13:39:56 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2] In-Reply-To: References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie wrote: >> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). >> >> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Replace spaces with \t in test properties file Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885177994 From alanb at openjdk.org Fri Feb 16 15:27:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Feb 2024 15:27:54 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 01:23:42 GMT, Alex Menkov wrote: > When I proposed this change 10 years ago, there was a push back: https://bugs.openjdk.org/browse/JDK-8005604. Right, the HPROF format was created to be independent of VM or any configuration. So JDK-8176520 is not really a bug, instead it is changing the meaning of the instance size field. Not opposed to doing that but I'm wondering if it means the version bytes at the start should be updated. I'm also wondering where the HPROF format is documented and if it now needs to be clarified. I think a CSR should be created to track this too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1948610723 From naoto at openjdk.org Fri Feb 16 16:55:57 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Feb 2024 16:55:57 GMT Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2] In-Reply-To: References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie wrote: >> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). >> >> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Replace spaces with \t in test properties file LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885586969 From ayang at openjdk.org Fri Feb 16 17:05:01 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 16 Feb 2024 17:05:01 GMT Subject: RFR: 8326065: Merge Space into ContiguousSpace Message-ID: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> Merging a super class into its single sub class. Test: tier1-6 ------------- Commit messages: - merge-space Changes: https://git.openjdk.org/jdk/pull/17891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17891&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326065 Stats: 401 lines in 8 files changed: 50 ins; 313 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/17891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17891/head:pull/17891 PR: https://git.openjdk.org/jdk/pull/17891 From cjplummer at openjdk.org Fri Feb 16 18:50:52 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Feb 2024 18:50:52 GMT Subject: RFR: 8326065: Merge Space into ContiguousSpace In-Reply-To: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> References: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> Message-ID: On Fri, 16 Feb 2024 17:00:15 GMT, Albert Mingkun Yang wrote: > Merging a super class into its single sub class. > > Test: tier1-6 The changes look good. It looks like the GenerationFactory removal is something that should have previously been done. Is that the case, or is there something about Space/ContiguousSpace merger that made it possible to remove GenerationFactory? ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17891#pullrequestreview-1885790369 From ayang at openjdk.org Fri Feb 16 19:04:55 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 16 Feb 2024 19:04:55 GMT Subject: RFR: 8326065: Merge Space into ContiguousSpace In-Reply-To: References: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> Message-ID: <8FZgGndY9lu5BUKqKxDuDHoViDPVs6h6luKO2gzRbdg=.380c1b2c-6eb3-45ab-83f3-f2b07928344f@github.com> On Fri, 16 Feb 2024 18:48:47 GMT, Chris Plummer wrote: > It looks like the GenerationFactory removal is something that should have previously been done. True; I overlooked it until the removal of `SpaceClosure` in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17891#issuecomment-1949131022 From sspitsyn at openjdk.org Fri Feb 16 20:40:52 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Feb 2024 20:40:52 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: References: Message-ID: <-H0X-wr0VZPPE0LzKWCUKxwnETYQqVvTX-1UJGOIs3E=.641cb82e-e414-476e-8452-f0f2c473f473@github.com> On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote: > This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. > > The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` > > This addresses a category of NULL uses that wasn't dealt with by: > [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). > > Testing: > - TBD: run mach5 tiers1-3 Thank you for review, Coleen! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1949300764 From amenkov at openjdk.org Fri Feb 16 21:06:54 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Feb 2024 21:06:54 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 15:25:38 GMT, Alan Bateman wrote: > > When I proposed this change 10 years ago, there was a push back: https://bugs.openjdk.org/browse/JDK-8005604. > > Right, the HPROF format was created to be independent of VM or any configuration. So JDK-8176520 is not really a bug, instead it is changing the meaning of the instance size field. Not opposed to doing that but I'm wondering if it means the version bytes at the start should be updated. I'm also wondering where the HPROF format is documented and if it now needs to be clarified. I think a CSR should be created to track this too. Thank you for the feedback @AlanBateman! Yes, this is not a bug, I've changed issue type to "enhancement". I don't think we need to bump format version. The format is not changed. New meaning of the field can be easy detected by checking "instance size" value for `lava.lang.Object` class (or any other class with no fields) - if it's > 0, then the field for all classes contain real instance size. There is no official hprof format spec (but we have an issue to create it), the only spec are comments in the source code (2 identical copies in VM heapDumper C++ code and in SA java code). The description of the field is quite general: "u4 instance size (in bytes)" I can change it to "instance size in the heap (in bytes)" ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1949332767 From sspitsyn at openjdk.org Fri Feb 16 21:25:01 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Feb 2024 21:25:01 GMT Subject: Integrated: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote: > This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. > > The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` > > This addresses a category of NULL uses that wasn't dealt with by: > [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). > > Testing: > - TBD: run mach5 tiers1-3 This pull request has now been integrated. Changeset: 267780bf Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/267780bf0adf4bfd831fbc04347e297fa8f3bb01 Stats: 110 lines in 5 files changed: 0 ins; 0 del; 110 mod 8324680: Replace NULL with nullptr in JVMTI generated code Reviewed-by: amenkov, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/17866 From kbarrett at openjdk.org Fri Feb 16 21:47:04 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 16 Feb 2024 21:47:04 GMT Subject: RFR: 8326090: Rename jvmti_aod.h Message-ID: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> Please review this trivial change that renames the file test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.h to jvmti_aod.hpp, and replace uses of NULL in the file. The #include updates were performed mechanically, and build would fail if there were mistakes. All of the including files have already had their copyrights updated recently, as part of JDK-8324681. So the only interesting (for some minimal value of "interesting") changes are in the renamed file. Testing: mach5 tier1 ------------- Commit messages: - rename NULLs in jvmti_aod.hpp - rename jvmti_aod.h Changes: https://git.openjdk.org/jdk/pull/17895/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17895&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326090 Stats: 33 lines in 27 files changed: 0 ins; 0 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/17895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17895/head:pull/17895 PR: https://git.openjdk.org/jdk/pull/17895 From cjplummer at openjdk.org Sat Feb 17 01:42:56 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 17 Feb 2024 01:42:56 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 02:45:26 GMT, Alex Menkov wrote: >> The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) >> >> Testing: tier1, tier2, tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > test bug id Can't the instance size as currently computed be computed by hprof tool vendors using class information already present in the hprof file (list of class fields and types, class hierarchy info, etc)? If so, then they have recourse if they prefer the current representation of "instance size", and manually computing the size in this manner would work with older hprof files too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1949580967 From amenkov at openjdk.org Sat Feb 17 02:32:55 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 17 Feb 2024 02:32:55 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Sat, 17 Feb 2024 01:40:44 GMT, Chris Plummer wrote: > Can't the instance size as currently computed be computed by hprof tool vendors using class information already present in the hprof file (list of class fields and types, class hierarchy info, etc)? If so, then they have recourse if they prefer the current representation of "instance size", and manually computing the size in this manner would work with older hprof files too. Yes, hprof tools can calculate current "instance size" value (all required class information is present in hprof, it's required to parse HPROF_GC_INSTANCE_DUMP records). They do not rely on "instance size" field, instead they calculate "actual" size from class/field information using tricks to detect header size, alignment/padding, compressed oops. This logic will continue to work with old and new hprof files, but tool vendors can detect "new" hprof and use "actual instance size" value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1949611174 From amenkov at openjdk.org Sat Feb 17 02:41:20 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 17 Feb 2024 02:41:20 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v3] In-Reply-To: References: Message-ID: <-ncgmJ585uqNSp1vIbXfcDM4rNPmoESFlHLStOlkQXM=.3d1cef9e-bc5b-4239-9937-d04f88a8ecd2@github.com> > The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) > > Testing: tier1, tier2, tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: split test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17855/files - new: https://git.openjdk.org/jdk/pull/17855/files/abba6396..2a5626d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17855&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17855&range=01-02 Stats: 137 lines in 2 files changed: 126 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17855.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17855/head:pull/17855 PR: https://git.openjdk.org/jdk/pull/17855 From sspitsyn at openjdk.org Sat Feb 17 12:07:14 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 17 Feb 2024 12:07:14 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v10] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: cloned an nsk/jvmti test to provide test coverage for virtual threads; fixed vthread related issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/c8b8e376..04da0cf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=08-09 Stats: 431 lines in 5 files changed: 415 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From dcubed at openjdk.org Sun Feb 18 15:50:01 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 18 Feb 2024 15:50:01 GMT Subject: RFR: 8326117: ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode Message-ID: Trivial fixes to ProblemList a couple of tests: [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode [JDK-8326120](https://bugs.openjdk.org/browse/JDK-8326120) ProblemList sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh on macosx-aarch64 ------------- Commit messages: - 8326120: ProblemList sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh on macosx-aarch64 - 8326117: ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode Changes: https://git.openjdk.org/jdk/pull/17904/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17904&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326117 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17904.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17904/head:pull/17904 PR: https://git.openjdk.org/jdk/pull/17904 From alanb at openjdk.org Sun Feb 18 16:31:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 18 Feb 2024 16:31:53 GMT Subject: RFR: 8326117: ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 14:56:03 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a couple of tests: > [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode > [JDK-8326120](https://bugs.openjdk.org/browse/JDK-8326120) ProblemList sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh on macosx-aarch64 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17904#pullrequestreview-1887280515 From dcubed at openjdk.org Sun Feb 18 17:13:53 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 18 Feb 2024 17:13:53 GMT Subject: RFR: 8326117: ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 16:28:51 GMT, Alan Bateman wrote: >> Trivial fixes to ProblemList a couple of tests: >> [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode >> [JDK-8326120](https://bugs.openjdk.org/browse/JDK-8326120) ProblemList sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh on macosx-aarch64 > > Marked as reviewed by alanb (Reviewer). @AlanBateman - Thanks for the review! Especially on a Sunday!! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17904#issuecomment-1951388559 From dcubed at openjdk.org Sun Feb 18 18:12:59 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 18 Feb 2024 18:12:59 GMT Subject: Integrated: 8326117: ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode In-Reply-To: References: Message-ID: <3H21dMMNv67KMdP-fJV-JuUTZsTSEheAPRxBtqLCjko=.9e7c7c39-d4cd-4f09-a78a-898b01e26bec@github.com> On Sun, 18 Feb 2024 14:56:03 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a couple of tests: > [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode > [JDK-8326120](https://bugs.openjdk.org/browse/JDK-8326120) ProblemList sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh on macosx-aarch64 This pull request has now been integrated. Changeset: 099b7442 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/099b744235a28331b99f7b429cf1e8abcb367c41 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod 8326117: ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode 8326120: ProblemList sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh on macosx-aarch64 Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17904 From jpai at openjdk.org Mon Feb 19 07:40:57 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 Feb 2024 07:40:57 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v11] In-Reply-To: References: Message-ID: On Sun, 17 Dec 2023 23:11:10 GMT, Chen Liang wrote: >> Summaries: >> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before >> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. >> 3. Most tests are included in tier1, but some are not: >> In `:jdk_io`: (tier2, part 2) >> >> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java >> test/jdk/java/io/Serializable/records/ProhibitedMethods.java >> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java >> >> In `:jdk_instrument`: (tier 3) >> >> test/jdk/java/lang/instrument/RetransformAgent.java >> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java >> test/jdk/java/lang/instrument/asmlib/Instrumentor.java >> >> >> @asotona Would you mind reviewing? > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix the 2 failing tests and add notes I see that this PR was approved a month back and there haven't been any changes to the PR since this (which is a good thing). I'll run this against our internal CI to make sure this still works as expected and will sponsor this later today, if that run goes fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1951862915 From alanb at openjdk.org Mon Feb 19 09:02:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Feb 2024 09:02:55 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Sat, 17 Feb 2024 02:30:03 GMT, Alex Menkov wrote: > Can't the instance size as currently computed be computed by hprof tool vendors using class information already present in the hprof file (list of class fields and types, class hierarchy info, etc)? That would still be based on VM independent sizes. I think what Alex is looking for is to have HotSpot VM specific sizes be included in the heap dump. I suspect this will require rev'ing the HPROF format, in which case it opens the potential to include object layout information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1951984754 From sroy at openjdk.org Mon Feb 19 10:05:17 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 19 Feb 2024 10:05:17 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/c6332f67..f5693f47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=21-22 Stats: 16 lines in 1 file changed: 8 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From sroy at openjdk.org Mon Feb 19 10:09:00 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 19 Feb 2024 10:09:00 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com> Message-ID: On Fri, 16 Feb 2024 12:50:37 GMT, Thomas Stuefe wrote: > * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future) I have done it now. This is just to make the developer aware that this was the design decision taken ? @tstuefe ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1952105754 From mdoerr at openjdk.org Mon Feb 19 10:19:02 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 19 Feb 2024 10:19:02 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 19 Feb 2024 10:05:17 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/hotspot/os/aix/os_aix.cpp line 1185: > 1183: // Shared object in .so format dont have braces, hence they get removed for archives with members. > 1184: if (error_code == EACCES || error_code == ENOENT) { > 1185: if (strlen(new_extension) > strlen(old_extension)){ I think this should better be an assertion because the extensions are constants. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494317702 From jkern at openjdk.org Mon Feb 19 10:45:00 2024 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 19 Feb 2024 10:45:00 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> On Mon, 19 Feb 2024 10:05:17 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/hotspot/os/aix/os_aix.cpp line 1181: > 1179: // First try to load the existing file. > 1180: result = dll_load_library(filename, ebuf, ebuflen); > 1181: int error_code = errno; this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494354118 From magnus.ihse.bursie at oracle.com Mon Feb 19 10:55:37 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 19 Feb 2024 11:55:37 +0100 Subject: Hotspot symbol visibility In-Reply-To: <97081168-46cc-4b9c-9721-add8f8b0c21a@littlepinkcloud.com> References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com> <97081168-46cc-4b9c-9721-add8f8b0c21a@littlepinkcloud.com> Message-ID: <4ba080b7-d18f-4fe4-91d2-f177542de158@oracle.com> On 2024-02-18 11:15, Andrew Haley wrote: > On 2/14/24 10:06, Magnus Ihse Bursie wrote: >> My takeaway from the discussions is that we are most likely exporting a >> way too broad set of symbols to SA. It seems likely that this set can be >> drastically cut down. Actually getting an understanding of exactly which >> symbols SA need seem like a very good first step. >> >> So, is this a journey anyone would be interested in embarkering on? I >> will help as much as I can from a build PoV, but I have no clue >> whatsoever about what SA needs. > > Alternatively, we have separate debuginfo. SA can use the debug symbols, > allowing us to strip all others. What's wrong with this reasoning? > I don't know if there is anything wrong with that reasoning. It seems reasonable. I also hope that we won't need to take the detour of first generating the symbols and then strip them, but instead can add them directly to the debuginfo, if we should choose to do things this way. Can anyone from serviceability chip in? Would it be okay for SA to require a .debuginfo or .diz file to be able to extract all the internal hotspot symbols? /Magnus From sroy at openjdk.org Mon Feb 19 11:15:59 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 19 Feb 2024 11:15:59 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> Message-ID: On Mon, 19 Feb 2024 10:42:03 GMT, Joachim Kern wrote: > this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call. As i see the code in Aix_dlopen , there is no additional functional call after the dlopen which might change the errno . Could you tell me the how the errno would get overriden ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494389934 From sroy at openjdk.org Mon Feb 19 11:16:00 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 19 Feb 2024 11:16:00 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 19 Feb 2024 10:15:59 GMT, Martin Doerr wrote: >> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/hotspot/os/aix/os_aix.cpp line 1185: > >> 1183: // Shared object in .so format dont have braces, hence they get removed for archives with members. >> 1184: if (error_code == EACCES || error_code == ENOENT) { >> 1185: if (strlen(new_extension) > strlen(old_extension)){ > > I think this should better be an assertion because the extensions are constants. As assertions are not supported in debug builds i did not use assert. May i know what is the purpose of assert,in general, as per design ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494392043 From jkern at openjdk.org Mon Feb 19 12:18:04 2024 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 19 Feb 2024 12:18:04 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> Message-ID: On Mon, 19 Feb 2024 11:11:23 GMT, Suchismith Roy wrote: >> src/hotspot/os/aix/os_aix.cpp line 1181: >> >>> 1179: // First try to load the existing file. >>> 1180: result = dll_load_library(filename, ebuf, ebuflen); >>> 1181: int error_code = errno; >> >> this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call. > >> this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call. > > As i see the code in Aix_dlopen , there is no additional functional call after the dlopen which might change the errno . Could you tell me the how the errno would get overriden ? Suchi, errno is a global static variable. If some runtime API sets it, it will continue to have this value until the next runtime call updates it. If you call dll_load_library, there are many execution paths not passing dlopen(). So you receive an errno from some unknown runtime API called before. The correct errno handling is: errno = 0; runtime_API_which_might_set_errno_in_error_case(); error_code = errno; But what you really need is the result of the `search_file_in_LIBPATH(...)` call in `Aix_dlopen()`. If it is false, then the error_report starts with the string "Could not load module . ....." This is called in any case. A `dlopen()` is not called in any case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494459722 From sroy at openjdk.org Mon Feb 19 13:02:59 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 19 Feb 2024 13:02:59 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> Message-ID: <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com> On Mon, 19 Feb 2024 12:15:22 GMT, Joachim Kern wrote: >>> this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call. >> >> As i see the code in Aix_dlopen , there is no additional functional call after the dlopen which might change the errno . Could you tell me the how the errno would get overriden ? > > Suchi, errno is a global static variable. If some runtime API sets it, it will continue to have this value until the next runtime call updates it. If you call dll_load_library, there are many execution paths not passing dlopen(). So you receive an errno from some unknown runtime API called before. The correct errno handling is: > > errno = 0; > runtime_API_which_might_set_errno_in_error_case(); > error_code = errno; > > But what you really need is the result of the `search_file_in_LIBPATH(...)` call in `Aix_dlopen()`. If it is false, then the error_report starts with the string "Could not load module . ....." > This is called in any case. A `dlopen()` is not called in any case. Thanks for the detailed explanation @JoKern65 . Do then in this errno check may not be necessary ? or can we still set errno and access it some way ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494516185 From sspitsyn at openjdk.org Mon Feb 19 13:13:25 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Feb 2024 13:13:25 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v11] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fixed minimal build issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/04da0cf8..63706e51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=09-10 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From jkern at openjdk.org Mon Feb 19 13:27:59 2024 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 19 Feb 2024 13:27:59 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com> Message-ID: On Mon, 19 Feb 2024 13:00:01 GMT, Suchismith Roy wrote: >> Suchi, errno is a global static variable. If some runtime API sets it, it will continue to have this value until the next runtime call updates it. If you call dll_load_library, there are many execution paths not passing dlopen(). So you receive an errno from some unknown runtime API called before. The correct errno handling is: >> >> errno = 0; >> runtime_API_which_might_set_errno_in_error_case(); >> error_code = errno; >> >> But what you really need is the result of the `search_file_in_LIBPATH(...)` call in `Aix_dlopen()`. If it is false, then the error_report starts with the string "Could not load module . ....." >> This is called in any case. A `dlopen()` is not called in any case. > > Thanks for the detailed explanation @JoKern65 . Do then in this errno check may not be necessary ? or can we still set errno and access it some way ? In this special case here I would not use errno, but the string returned in ebuf, in case the result is nullptr. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494546476 From sspitsyn at openjdk.org Mon Feb 19 13:28:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Feb 2024 13:28:56 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v9] In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 06:01:19 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001 > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1496: > >> 1494: nWant = wantList->length(); >> 1495: >> 1496: if (mon != nullptr) { > > Shouldn't the call to `get_pending_threads` only happen if `mon != nullptr`? Otherwise the `wantList` has to be empty. Good catch. I've moved it under the `if (mon != nullptr) {` condition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1494547012 From sspitsyn at openjdk.org Mon Feb 19 13:35:58 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Feb 2024 13:35:58 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v9] In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 06:09:40 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001 > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1500: > >> 1498: for (int i = 0; i < nWait; i++) { >> 1499: if (waiter == nullptr || (i != 0 && waiter == mon->first_waiter())) { >> 1500: // robustness: the waiting list has gotten smaller > > We are at a safepoint so I don't see how the wait list can shrink. I initially thought perhaps a waiter could timeout, but the code that does the timed park is wrapped in ` ThreadBlockInVMPreprocess` which will block at a safepoint if one is active. Thank you for the question. The `nWait` count we got from the `mon->waiters()` can include the threads that are re-entering the monitor after being notified. Here we are correcting the actual number of the waiting threads by excluding those re-entering the monitor. The comment need an update to explain it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1494556207 From stuefe at openjdk.org Mon Feb 19 13:59:02 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 19 Feb 2024 13:59:02 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com> Message-ID: <75Cr_jXGHaVJVyHADMj5BNn1x12D56RtAprZ1AY3Q6E=.91bc8cc3-0f91-48b6-9509-7727cc6f8c81@github.com> On Mon, 19 Feb 2024 13:25:28 GMT, Joachim Kern wrote: >> Thanks for the detailed explanation @JoKern65 . Do then in this errno check may not be necessary ? or can we still set errno and access it some way ? > > In this special case here I would not use errno, but the string returned in ebuf, in case the result is nullptr. Argh, I keep forgetting `dlopen` does not set errno (at least its not guaranteed by the standard). Ok, in this case, I would not analyze the string either because it may be locale-dependent. Never mind then; I'd thought this would be easy. One could probably use load() instead of dlopen() on AIX, but that change would require more investigations to see if load() and dlopen() are equivalent. Okay, in that case just skip the errno test and call the second dlopen directly. Lets hope for the best then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494586044 From liach at openjdk.org Mon Feb 19 14:10:01 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Feb 2024 14:10:01 GMT Subject: Integrated: 8294977: Convert test/jdk/java tests from ASM library to Classfile API In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 02:43:41 GMT, Chen Liang wrote: > Summaries: > 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before > 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. > 3. Most tests are included in tier1, but some are not: > In `:jdk_io`: (tier2, part 2) > > test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > test/jdk/java/io/Serializable/records/ProhibitedMethods.java > test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > > In `:jdk_instrument`: (tier 3) > > test/jdk/java/lang/instrument/RetransformAgent.java > test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java > test/jdk/java/lang/instrument/asmlib/Instrumentor.java > > > @asotona Would you mind reviewing? This pull request has now been integrated. Changeset: f6d7e30b Author: Chen Liang Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/f6d7e30b84fedbf42077526610ba7a5bcfaece4c Stats: 1829 lines in 31 files changed: 350 ins; 717 del; 762 mod 8294977: Convert test/jdk/java tests from ASM library to Classfile API Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/13009 From jpai at openjdk.org Mon Feb 19 14:10:01 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 Feb 2024 14:10:01 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v11] In-Reply-To: References: Message-ID: On Sun, 17 Dec 2023 23:11:10 GMT, Chen Liang wrote: >> Summaries: >> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before >> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. >> 3. Most tests are included in tier1, but some are not: >> In `:jdk_io`: (tier2, part 2) >> >> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java >> test/jdk/java/io/Serializable/records/ProhibitedMethods.java >> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java >> >> In `:jdk_instrument`: (tier 3) >> >> test/jdk/java/lang/instrument/RetransformAgent.java >> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java >> test/jdk/java/lang/instrument/asmlib/Instrumentor.java >> >> >> @asotona Would you mind reviewing? > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix the 2 failing tests and add notes tier1, tier2 and tier3 tests went fine with these changes on top of latest master branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1952526367 From kevin.walls at oracle.com Mon Feb 19 15:04:15 2024 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 19 Feb 2024 15:04:15 +0000 Subject: Hotspot symbol visibility In-Reply-To: <4ba080b7-d18f-4fe4-91d2-f177542de158@oracle.com> References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com> <97081168-46cc-4b9c-9721-add8f8b0c21a@littlepinkcloud.com> <4ba080b7-d18f-4fe4-91d2-f177542de158@oracle.com> Message-ID: Hi - I've observed it being problematic for customers have access to .debuginfo files, either to acquire the .debuginfo bundles or to get them in the relevant place/machine. This has I'm sure been a sticking point for support many times. It would be great to avoid that. The SA needs the gHotSpotVM.... symbols, and the vtable symbols. The symbols need to be in the binary, but not necessarily findable by "dlsym", as it does ELF symbol lookup work itself (notes in JDK-8017234). We would need to test if there are SA failures if these symbols are not exported?... (There are some issues mentioned in JDK-8017234, maybe they are still true.) -----Original Message----- From: serviceability-dev On Behalf Of Magnus Ihse Bursie Sent: 19 February 2024 10:56 To: Andrew Haley ; hotspot-dev at openjdk.org; serviceability-dev at openjdk.java.net Subject: Re: Hotspot symbol visibility Importance: High On 2024-02-18 11:15, Andrew Haley wrote: > On 2/14/24 10:06, Magnus Ihse Bursie wrote: >> My takeaway from the discussions is that we are most likely exporting >> a way too broad set of symbols to SA. It seems likely that this set >> can be drastically cut down. Actually getting an understanding of >> exactly which symbols SA need seem like a very good first step. >> >> So, is this a journey anyone would be interested in embarkering on? I >> will help as much as I can from a build PoV, but I have no clue >> whatsoever about what SA needs. > > Alternatively, we have separate debuginfo. SA can use the debug > symbols, allowing us to strip all others. What's wrong with this reasoning? > I don't know if there is anything wrong with that reasoning. It seems reasonable. I also hope that we won't need to take the detour of first generating the symbols and then strip them, but instead can add them directly to the debuginfo, if we should choose to do things this way. Can anyone from serviceability chip in? Would it be okay for SA to require a .debuginfo or .diz file to be able to extract all the internal hotspot symbols? /Magnus From sspitsyn at openjdk.org Mon Feb 19 15:33:23 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Feb 2024 15:33:23 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v12] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: addressed comments from David ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/63706e51..81b7787b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=10-11 Stats: 12 lines in 1 file changed: 8 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From ihse at openjdk.org Mon Feb 19 16:16:00 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 19 Feb 2024 16:16:00 GMT Subject: Integrated: 8325950: Make sure all files in the JDK pass jcheck In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com> Message-ID: <8lQWgT0JhzAP5uuraMs8UjJXJcyTacHziySbnLN9XaQ=.16d4233d-1815-4cf8-8761-368fe425a131@github.com> On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote: > Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes). > > I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base. This pull request has now been integrated. Changeset: 5c5a282f Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/5c5a282f91dd28b306673ca2bcc30dec451e7a7d Stats: 113 lines in 38 files changed: 0 ins; 10 del; 103 mod 8325950: Make sure all files in the JDK pass jcheck Reviewed-by: prr, wetmore, erikj, naoto ------------- PR: https://git.openjdk.org/jdk/pull/17871 From sroy at openjdk.org Mon Feb 19 17:16:34 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 19 Feb 2024 17:16:34 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v24] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision: - remove error_code - revert error code check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/f5693f47..c6b3deb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=22-23 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From sroy at openjdk.org Mon Feb 19 17:20:02 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 19 Feb 2024 17:20:02 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: <75Cr_jXGHaVJVyHADMj5BNn1x12D56RtAprZ1AY3Q6E=.91bc8cc3-0f91-48b6-9509-7727cc6f8c81@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com> <75Cr_jXGHaVJVyHADMj5BNn1x12D56RtAprZ1AY3Q6E=.91bc8cc3-0f91-48b6-9509-7727cc6f8c81@github.com> Message-ID: On Mon, 19 Feb 2024 13:55:58 GMT, Thomas Stuefe wrote: >> In this special case here I would not use errno, but the string returned in ebuf, in case the result is nullptr. > > Argh, I keep forgetting `dlopen` does not set errno (at least its not guaranteed by the standard). > > Ok, in this case, I would not analyze the string either because it may be locale-dependent. > > Never mind then; I'd thought this would be easy. One could probably use load() instead of dlopen() on AIX, but that change would require more investigations to see if load() and dlopen() are equivalent. > > Okay, in that case just skip the errno test and call the second dlopen directly. Lets hope for the best then. Sure .thank for all the info. This is great learning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494859583 From jsjolen at openjdk.org Mon Feb 19 20:07:56 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 19 Feb 2024 20:07:56 GMT Subject: RFR: 8321971: Improve the user name detection logic in perfMemory get_user_name_slow [v3] In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 12:18:36 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - remove redundant if block >> - merge latest from master branch >> - David's review comments - reduce if blocks and release the array outside if block >> - David's review comment - punctuation >> - 8321971: Improve the user name detection logic in perfMemory get_user_name_slow > > Just a note - I have incorporated the review comments, except from Johan which I'm still investigating and will update this PR soon. Hi @jaikiran, I looked at the `snprintf` issue, the easiest way of fixing this is this: ```c++ { char* name = NEW_C_HEAP_ARRAY(char, nbytes, mtInternal); int bytes_required = snprintf(name, nbytes, "%s/%d", dirname, pid); if (bytes_required >= nbytes) { // Our output was truncated FREE_C_HEAP_ARRAY(name); nbytes = bytes_required; name = NEW_C_HEAP_ARRAY(char, nbytes, mtInternal); bytes_required = snprintf(name, nbytes, "%s/%d", dirname, pid); assert(bytes_required < nbytes, "must be"); } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/17104#issuecomment-1953095597 From dholmes at openjdk.org Tue Feb 20 06:17:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Feb 2024 06:17:55 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v12] In-Reply-To: References: Message-ID: <4B3DWXFwEnHy-pkzhr3L-LzQi3O0hdenzXqb5V1OejQ=.67044e45-777b-4fbc-af5e-de29348a2247@github.com> On Mon, 19 Feb 2024 15:33:23 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: addressed comments from David test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 54: > 52: > 53: static Object lockCheck = new Object(); > 54: static Thread thr[] = new Thread[NUMBER_OF_THREADS]; Nit: the `[]` go on the type not the variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1495292810 From sroy at openjdk.org Tue Feb 20 08:59:00 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 20 Feb 2024 08:59:00 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com> <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com> <75Cr_jXGHaVJVyHADMj5BNn1x12D56RtAprZ1AY3Q6E=.91bc8cc3-0f91-48b6-9509-7727cc6f8c81@github.com> Message-ID: On Mon, 19 Feb 2024 17:16:53 GMT, Suchismith Roy wrote: >> Argh, I keep forgetting `dlopen` does not set errno (at least its not guaranteed by the standard). >> >> Ok, in this case, I would not analyze the string either because it may be locale-dependent. >> >> Never mind then; I'd thought this would be easy. One could probably use load() instead of dlopen() on AIX, but that change would require more investigations to see if load() and dlopen() are equivalent. >> >> Okay, in that case just skip the errno test and call the second dlopen directly. Lets hope for the best then. > > Sure .thank for all the info. This is great learning. reverted the error code handling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1495450839 From mdoerr at openjdk.org Tue Feb 20 09:17:02 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 20 Feb 2024 09:17:02 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v24] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 19 Feb 2024 17:16:34 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision: > > - remove error_code > - revert error code check src/hotspot/os/aix/os_aix.cpp line 1185: > 1183: // Shared object in .so format dont have braces, hence they get removed for archives with members. > 1184: if (result == nullptr) { > 1185: assert(strlen(new_extension) < strlen(old_extension),"New extension length must be less than existing one"); `<=` would be sufficient. Please add a whitespace after `,`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1495478067 From sroy at openjdk.org Tue Feb 20 09:27:15 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 20 Feb 2024 09:27:15 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v25] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: remove space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/c6b3deb3..664e41a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=23-24 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From coleenp at openjdk.org Tue Feb 20 15:17:55 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 20 Feb 2024 15:17:55 GMT Subject: RFR: 8326090: Rename jvmti_aod.h In-Reply-To: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> References: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> Message-ID: On Fri, 16 Feb 2024 21:42:18 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.h to jvmti_aod.hpp, > and replace uses of NULL in the file. > > The #include updates were performed mechanically, and build would fail if > there were mistakes. All of the including files have already had their > copyrights updated recently, as part of JDK-8324681. So the only interesting > (for some minimal value of "interesting") changes are in the renamed file. > > Testing: mach5 tier1 Looks good and trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17895#pullrequestreview-1890708971 From cjplummer at openjdk.org Tue Feb 20 21:32:54 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Feb 2024 21:32:54 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: On Mon, 19 Feb 2024 09:00:16 GMT, Alan Bateman wrote: > > Can't the instance size as currently computed be computed by hprof tool vendors using class information already present in the hprof file (list of class fields and types, class hierarchy info, etc)? > That would still be based on VM independent sizes. Yes, that is the point. The current version of the value is VM independent. If any tool is relying on that fact, then after Alex's changes they can still calculate the VM independent size. The info they need for that is still in the hprof file, and this calculation will also work with hprof files created before Alex's changes. > I think what Alex is looking for is to have HotSpot VM specific sizes be included in the heap dump. I suspect this will require rev'ing the HPROF format, in which case it opens the potential to include object layout information If it requires a rev of the HPROF spec, then likely the change is just going to be tabled, which would be unfortunate since this change is very simple to make and was requested by an hprof tool vendor. It would be good if just a CSR could be used to document the change. You can argue that it is not even a spec change, but just a clarification of the spec combined with updating the heapdump code to support the clarification. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1955139965 From sspitsyn at openjdk.org Tue Feb 20 23:48:06 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Feb 2024 23:48:06 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v13] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: addressed minor issue with use of []; corrected the test desctiption ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/81b7787b..e095cffe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=11-12 Stats: 13 lines in 1 file changed: 5 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From sspitsyn at openjdk.org Tue Feb 20 23:48:06 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Feb 2024 23:48:06 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v12] In-Reply-To: <4B3DWXFwEnHy-pkzhr3L-LzQi3O0hdenzXqb5V1OejQ=.67044e45-777b-4fbc-af5e-de29348a2247@github.com> References: <4B3DWXFwEnHy-pkzhr3L-LzQi3O0hdenzXqb5V1OejQ=.67044e45-777b-4fbc-af5e-de29348a2247@github.com> Message-ID: On Tue, 20 Feb 2024 06:15:07 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: addressed comments from David > > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 54: > >> 52: >> 53: static Object lockCheck = new Object(); >> 54: static Thread thr[] = new Thread[NUMBER_OF_THREADS]; > > Nit: the `[]` go on the type not the variable. Thanks, fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1496688629 From sspitsyn at openjdk.org Tue Feb 20 23:51:53 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Feb 2024 23:51:53 GMT Subject: RFR: 8326090: Rename jvmti_aod.h In-Reply-To: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> References: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> Message-ID: <63rOo1CFAlCbbeKYSDiUdWbCA72p0TSbtFZHcDZLCMk=.069ab8ba-aeaa-4508-9264-6b698c29bfcb@github.com> On Fri, 16 Feb 2024 21:42:18 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.h to jvmti_aod.hpp, > and replace uses of NULL in the file. > > The #include updates were performed mechanically, and build would fail if > there were mistakes. All of the including files have already had their > copyrights updated recently, as part of JDK-8324681. So the only interesting > (for some minimal value of "interesting") changes are in the renamed file. > > Testing: mach5 tier1 Looks good. Thank you for taking care about it. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17895#pullrequestreview-1891789123 From kbarrett at openjdk.org Wed Feb 21 03:13:12 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Feb 2024 03:13:12 GMT Subject: RFR: 8326090: Rename jvmti_aod.h [v2] In-Reply-To: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> References: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> Message-ID: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.h to jvmti_aod.hpp, > and replace uses of NULL in the file. > > The #include updates were performed mechanically, and build would fail if > there were mistakes. All of the including files have already had their > copyrights updated recently, as part of JDK-8324681. So the only interesting > (for some minimal value of "interesting") changes are in the renamed file. > > Testing: mach5 tier1 Kim Barrett 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 jvmti_aod - rename NULLs in jvmti_aod.hpp - rename jvmti_aod.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17895/files - new: https://git.openjdk.org/jdk/pull/17895/files/983aadad..29463e74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17895&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17895&range=00-01 Stats: 3977 lines in 183 files changed: 1394 ins; 1179 del; 1404 mod Patch: https://git.openjdk.org/jdk/pull/17895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17895/head:pull/17895 PR: https://git.openjdk.org/jdk/pull/17895 From kbarrett at openjdk.org Wed Feb 21 03:13:13 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Feb 2024 03:13:13 GMT Subject: RFR: 8326090: Rename jvmti_aod.h [v2] In-Reply-To: References: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> Message-ID: <2wwyAE1yIr9HYhAK3OSQzjy3A0tDFQou84B40I8rV-w=.f5c6a522-01b5-4396-a743-2f02e687b6af@github.com> On Tue, 20 Feb 2024 15:15:35 GMT, Coleen Phillimore wrote: >> Kim Barrett 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 jvmti_aod >> - rename NULLs in jvmti_aod.hpp >> - rename jvmti_aod.h > > Looks good and trivial. Thanks for reviewing, @coleenp and @sspitsyn . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17895#issuecomment-1955795299 From kbarrett at openjdk.org Wed Feb 21 03:13:13 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Feb 2024 03:13:13 GMT Subject: Integrated: 8326090: Rename jvmti_aod.h In-Reply-To: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> References: <8ZNwxgeazpHMpHgYU-JtljryrNCMEvBGWUXTK_p5pA4=.bb1ab8f3-0b39-4fe6-97ed-86abf54e89eb@github.com> Message-ID: On Fri, 16 Feb 2024 21:42:18 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.h to jvmti_aod.hpp, > and replace uses of NULL in the file. > > The #include updates were performed mechanically, and build would fail if > there were mistakes. All of the including files have already had their > copyrights updated recently, as part of JDK-8324681. So the only interesting > (for some minimal value of "interesting") changes are in the renamed file. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 27003b53 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/27003b53bbb565123678a7feca74628b29991a5c Stats: 33 lines in 27 files changed: 0 ins; 0 del; 33 mod 8326090: Rename jvmti_aod.h Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/17895 From amenkov at openjdk.org Wed Feb 21 03:56:53 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 21 Feb 2024 03:56:53 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v2] In-Reply-To: References: Message-ID: <1InsSRef1pDsgZGHe7tpfQJR3L6EzB42Sg7VFdcH75I=.6b0579b9-a9ed-471c-8303-be75f8a446ff@github.com> On Mon, 19 Feb 2024 09:00:16 GMT, Alan Bateman wrote: > > Can't the instance size as currently computed be computed by hprof tool vendors using class information already present in the hprof file (list of class fields and types, class hierarchy info, etc)? > > That would still be based on VM independent sizes. I think what Alex is looking for is to have HotSpot VM specific sizes be included in the heap dump. I suspect this will require rev'ing the HPROF format, in which case it opens the potential to include object layout information. Some addition to what Chris said from my side. The current value of the field is VM independent, but to me it doesn't reflect the description. Reading "instance size (in bytes)" in the hprof description I interpret it as "how many bytes an instance of the class occupies in memory". As this value is not required for reading/parsing, I tend to consider current implementation as inaccurately reported value. Updating version of the hprof format is destructive. The only version info is the file header ("JAVA PROFILE 1.0.2"). Changing it would break all hprof tool. It would be good to include object layout information to heap dump file (as well as other useful data like information about virtual threads), but most likely this it's too risky to include it to hprof format and should be done as part of new file format development. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1955841131 From jaroslav.bachorik at datadoghq.com Wed Feb 21 09:29:06 2024 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 21 Feb 2024 10:29:06 +0100 Subject: Some JTREG tests crashing on linux-x86 in C2 code Message-ID: Hello, I have noticed that some of the JFR and SVC tests are crashing in C2 code with # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (x86_32.ad:1317), pid=5714, tid=5738 # Error: Unimplemented() # # JRE version: OpenJDK Runtime Environment (23.0) (build 23-internal-jbachorik-6252993573af535f57be21164026d6e54733a175) # Java VM: OpenJDK Server VM (23-internal-jbachorik-6252993573af535f57be21164026d6e54733a175, mixed mode, sharing, tiered, g1 gc, linux-x86) # Problematic frame: # V [libjvm.so+0x150f48] MachSpillCopyNode::implementation(CodeBuffer*, PhaseRegAlloc*, bool, outputStream*) const+0x1c78 # # CreateCoredumpOnCrash turned off, no core file dumped # # JFR recording file will be written. Location: /home/runner/work/jdk-skogsluft/jdk-skogsluft/build/run-test-prebuilt/test-support/jtreg_test_jdk_jdk_jfr/scratch/1/hs_err_pid5714.jfr # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # FIrst I thought they might have been related to some of my changes but then I ran those tests on master branch ( https://github.com/skogsluft/jdk-skogsluft/actions/runs/7975954841) and I could observe the same crashes there. I assume the 32bit JVM is not critical - but I wanted to bring this up, just in case. Cheers, -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sspitsyn at openjdk.org Wed Feb 21 10:36:05 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Feb 2024 10:36:05 GMT Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly Message-ID: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified. The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note. CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly RN: [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly Testing: - tested with the mach5 tiers 1-6 ------------- Commit messages: - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly Changes: https://git.openjdk.org/jdk/pull/17944/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8256314 Stats: 46 lines in 5 files changed: 27 ins; 10 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17944.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944 PR: https://git.openjdk.org/jdk/pull/17944 From alanb at openjdk.org Wed Feb 21 19:15:56 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Feb 2024 19:15:56 GMT Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> Message-ID: On Wed, 21 Feb 2024 10:28:49 GMT, Serguei Spitsyn wrote: > The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. > With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified. > > The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note. > > CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly > RN: [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly > > Testing: > - tested with the mach5 tiers 1-6 src/java.se/share/data/jdwp/jdwp.spec line 1985: > 1983: "thread may be waiting to enter a monitor, or it may be waiting, via " > 1984: "the java.lang.Object.wait method, to re-enter a monitor after being " > 1985: "notified by another thread. " Interrupted or timeout in Object.wait are other reasons to be waiting to reenter. I'm wondering if this should be spelled out here. I see the JVMTI spec uses the phrase "regain" to cover the scenarios where a thread is waiting to reenter. In any case, I think the wording could be a smoother as reenter case isn't very clear. Here's an attempt as smoothing out the wording but it may be more than you want to include: "The thread may be waiting to enter the object's monitor, in the monitor's wait set and waiting in Object.wait, or in Object.wait waiting to reenter the monitor after being notified, interrupted, or timeout." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1498160800 From amenkov at openjdk.org Wed Feb 21 21:34:19 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 21 Feb 2024 21:34:19 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library Message-ID: VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). before jdk21 if attach listener fails to load required library, it returned error (case 1) from jdk21 attach listener always returns success (case 2) Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) Testing: - test/jdk/com/sun/tools; - tier1,tier2,tier5-svc ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/17954/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325530 Stats: 146 lines in 6 files changed: 106 ins; 16 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/17954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954 PR: https://git.openjdk.org/jdk/pull/17954 From amenkov at openjdk.org Wed Feb 21 21:34:19 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 21 Feb 2024 21:34:19 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 21:13:36 GMT, Alex Menkov wrote: > VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: > - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); > - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). > > before jdk21 if attach listener fails to load required library, it returned error (case 1) > from jdk21 attach listener always returns success (case 2) > Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. > > The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. > Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) > > Testing: > - test/jdk/com/sun/tools; > - tier1,tier2,tier5-svc src/hotspot/share/prims/jvmtiAgentList.cpp line 127: > 125: } > 126: > 127: void JvmtiAgentList::add(const char* name, const char* options, bool absolute_path) { `options` parameter should be const src/hotspot/share/prims/jvmtiAgentList.cpp line 131: > 129: } > 130: > 131: void JvmtiAgentList::add_xrun(const char* name, const char* options, bool absolute_path) { `options` parameter should be const src/hotspot/share/prims/jvmtiAgentList.cpp line 201: > 199: > 200: // Invokes Agent_OnAttach for agents loaded dynamically during runtime. > 201: jint JvmtiAgentList::load_agent(const char* agent_name, const char* absParam, The method never returns error, dropped value return type src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 402: > 400: } > 401: > 402: // Special-case the "load" command so that the right exception is We had special logic for "load" command in 2 places (here and in the loadAgentLibrary method) For simplification moved all logic to loadAgentLibrary() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498320621 PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498320775 PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498321476 PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498333650 From amenkov at openjdk.org Wed Feb 21 21:34:19 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 21 Feb 2024 21:34:19 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 21:16:46 GMT, Alex Menkov wrote: >> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: >> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); >> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). >> >> before jdk21 if attach listener fails to load required library, it returned error (case 1) >> from jdk21 attach listener always returns success (case 2) >> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. >> >> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. >> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) >> >> Testing: >> - test/jdk/com/sun/tools; >> - tier1,tier2,tier5-svc > > src/hotspot/share/prims/jvmtiAgentList.cpp line 201: > >> 199: >> 200: // Invokes Agent_OnAttach for agents loaded dynamically during runtime. >> 201: jint JvmtiAgentList::load_agent(const char* agent_name, const char* absParam, > > The method never returns error, dropped value return type only 1 caller (load_agent() from attachListener) extract `absParam` from attach command, other pass constants ("true" or "false") Moved conversion from string to bool there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498327164 From amenkov at openjdk.org Wed Feb 21 21:42:08 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 21 Feb 2024 21:42:08 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v2] In-Reply-To: References: Message-ID: > VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: > - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); > - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). > > before jdk21 if attach listener fails to load required library, it returned error (case 1) > from jdk21 attach listener always returns success (case 2) > Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. > > The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. > Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) > > Testing: > - test/jdk/com/sun/tools; > - tier1,tier2,tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: uncaught error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17954/files - new: https://git.openjdk.org/jdk/pull/17954/files/19f0822e..0304bae2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954 PR: https://git.openjdk.org/jdk/pull/17954 From lmesnik at openjdk.org Wed Feb 21 22:48:59 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 21 Feb 2024 22:48:59 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v13] In-Reply-To: References: Message-ID: On Tue, 20 Feb 2024 23:48:06 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: addressed minor issue with use of []; corrected the test desctiption Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 42: > 40: * - all the above is checked for both platform and virtual threads > 41: * @requires vm.jvmti > 42: * @compile ObjectMonitorUsage.java No need to have explicit compile for the test code. test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 48: > 46: public class ObjectMonitorUsage { > 47: > 48: final static int JCK_STATUS_BASE = 95; JCK_STATUS_BASE is not used, need to be removed. test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 72: > 70: * - zero threads waiting to be notified > 71: */ > 72: static void test1(boolean isVirtual) throws Error { no need to add throws for unchecked excption test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 204: > 202: > 203: // test virtual threads > 204: test1(false); shouldn't be true here? test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 37: > 35: static jvmtiCapabilities caps; > 36: static jint result = PASSED; > 37: static jboolean printdump = JNI_FALSE; if there are not too much logging, better just to enable log by default and remove this variable test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 105: > 103: err = jvmti->GetObjectMonitorUsage(obj, &inf); > 104: if (err == JVMTI_ERROR_MUST_POSSESS_CAPABILITY && !caps.can_get_monitor_info) { > 105: return; /* Ok, it's expected */ I think we don't need this path. test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 107: > 105: return; /* Ok, it's expected */ > 106: } else if (err != JVMTI_ERROR_NONE) { > 107: LOG("(GetMonitorInfo#%d) unexpected error: %s (%d)\n", you could use check_jvmti_status test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 117: > 115: LOG(">>> [%2d] owner: none (0x0)\n", count); > 116: } else { > 117: err = jvmti->GetThreadInfo(inf.owner, &tinf); need to check err status. test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 126: > 124: LOG(">>> waiters:\n"); > 125: for (j = 0; j < inf.waiter_count; j++) { > 126: err = jvmti->GetThreadInfo(inf.waiters[j], &tinf); need to check err. test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 31: > 29: > 30: final static int JCK_STATUS_BASE = 95; > 31: final static int NUMBER_OF_THREADS = 16; Better to remove the test if it already converted to avoid mess. ------------- PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1894528980 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498395120 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498385978 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498396928 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498388601 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498391687 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498392633 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498393662 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498393291 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498404333 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498394741 From sspitsyn at openjdk.org Wed Feb 21 22:54:55 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Feb 2024 22:54:55 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v13] In-Reply-To: References: Message-ID: On Tue, 20 Feb 2024 23:48:06 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: addressed minor issue with use of []; corrected the test desctiption Leonid, thank you for the comments. Will work on addressing them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1958221870 From sspitsyn at openjdk.org Thu Feb 22 05:44:55 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 05:44:55 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v13] In-Reply-To: References: Message-ID: <_U8xyOmY0TPvWjiU5R3GTVMTArlPVmBmAJx-SjuMHUw=.0074abe0-1ce1-41fd-bbca-6257024dc868@github.com> On Wed, 21 Feb 2024 22:23:27 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: addressed minor issue with use of []; corrected the test desctiption > > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 48: > >> 46: public class ObjectMonitorUsage { >> 47: >> 48: final static int JCK_STATUS_BASE = 95; > > JCK_STATUS_BASE is not used, need to be removed. Thanks, done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498672751 From sspitsyn at openjdk.org Thu Feb 22 06:03:57 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 06:03:57 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v13] In-Reply-To: References: Message-ID: <0_Cy_pSvPNQClMDFQDkz4z5LBK1ajGJbNdywx4kiyKQ=.fa711b33-8b76-4b5f-9817-e42c613109e8@github.com> On Wed, 21 Feb 2024 22:36:31 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: addressed minor issue with use of []; corrected the test desctiption > > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 72: > >> 70: * - zero threads waiting to be notified >> 71: */ >> 72: static void test1(boolean isVirtual) throws Error { > > no need to add throws for unchecked excption Fixed, thanks. > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 117: > >> 115: LOG(">>> [%2d] owner: none (0x0)\n", count); >> 116: } else { >> 117: err = jvmti->GetThreadInfo(inf.owner, &tinf); > > need to check err status. Fixed, thanks. > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 126: > >> 124: LOG(">>> waiters:\n"); >> 125: for (j = 0; j < inf.waiter_count; j++) { >> 126: err = jvmti->GetThreadInfo(inf.waiters[j], &tinf); > > need to check err. Done, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498688861 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498690913 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498688037 From sspitsyn at openjdk.org Thu Feb 22 06:08:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 06:08:56 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v13] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 22:34:19 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: addressed minor issue with use of []; corrected the test desctiption > > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 42: > >> 40: * - all the above is checked for both platform and virtual threads >> 41: * @requires vm.jvmti >> 42: * @compile ObjectMonitorUsage.java > > No need to have explicit compile for the test code. Fixed, thanks. > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 204: > >> 202: >> 203: // test virtual threads >> 204: test1(false); > > shouldn't be true here? Nice catch, thanks. Fixed now. > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 105: > >> 103: err = jvmti->GetObjectMonitorUsage(obj, &inf); >> 104: if (err == JVMTI_ERROR_MUST_POSSESS_CAPABILITY && !caps.can_get_monitor_info) { >> 105: return; /* Ok, it's expected */ > > I think we don't need this path. Yes. Fixed, thanks. > test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 107: > >> 105: return; /* Ok, it's expected */ >> 106: } else if (err != JVMTI_ERROR_NONE) { >> 107: LOG("(GetMonitorInfo#%d) unexpected error: %s (%d)\n", > > you could use check_jvmti_status Fixed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498694748 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498694426 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498693585 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498693206 From sspitsyn at openjdk.org Thu Feb 22 07:30:58 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 07:30:58 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v13] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 22:33:51 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: addressed minor issue with use of []; corrected the test desctiption > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 31: > >> 29: >> 30: final static int JCK_STATUS_BASE = 95; >> 31: final static int NUMBER_OF_THREADS = 16; > > Better to remove the test if it already converted to avoid mess. Agreed. I was thinking about the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498773675 From sspitsyn at openjdk.org Thu Feb 22 11:22:26 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 11:22:26 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v14] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: remove test objmonusage003; improve test ObjectMonitorUsage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/e095cffe..ef779169 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=12-13 Stats: 1353 lines in 9 files changed: 454 ins; 899 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From sspitsyn at openjdk.org Thu Feb 22 11:29:57 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 11:29:57 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v14] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 11:22:26 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: remove test objmonusage003; improve test ObjectMonitorUsage I've pushed an update which addresses test related review comments from Leonid and adds some test improvements: - remove the `nsk/jvmti` test `objmonusage003` which was converted into ObjectMonitorUsage - rename the test folder from `GetObjectMonitorUsage` to `ObjectMonitorUsage` for naming unification - add one more testing scenario: `test0` - add test specific thread names - address several minor review comments from Leonid - add better organized log messages ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1959255417 From sspitsyn at openjdk.org Thu Feb 22 13:24:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 13:24:56 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v2] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 21:42:08 GMT, Alex Menkov wrote: >> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: >> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); >> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). >> >> before jdk21 if attach listener fails to load required library, it returned error (case 1) >> from jdk21 attach listener always returns success (case 2) >> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. >> >> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. >> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) >> >> Testing: >> - test/jdk/com/sun/tools; >> - tier1,tier2,tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > uncaught error src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 113: > 111: } > 112: } else { > 113: String msg = "Failed to load agent library"; Nit: The line 113 can be moved above the line 99, so the `msg` could be also used at line 122 instead of a literal use of the string. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1499234830 From sspitsyn at openjdk.org Thu Feb 22 14:46:54 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 14:46:54 GMT Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly In-Reply-To: References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> Message-ID: On Wed, 21 Feb 2024 19:13:41 GMT, Alan Bateman wrote: >> The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. >> With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified. >> >> The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note. >> >> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly >> RN: [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly >> >> Testing: >> - tested with the mach5 tiers 1-6 > > src/java.se/share/data/jdwp/jdwp.spec line 1985: > >> 1983: "thread may be waiting to enter a monitor, or it may be waiting, via " >> 1984: "the java.lang.Object.wait method, to re-enter a monitor after being " >> 1985: "notified by another thread. " > > Interrupted or timeout in Object.wait are other reasons to be waiting to reenter. I'm wondering if this should be spelled out here. I see the JVMTI spec uses the phrase "regain" to cover the scenarios where a thread is waiting to reenter. > > In any case, I think the wording could be a smoother as reenter case isn't very clear. Here's an attempt at smoothing out the wording but it may be more than you want to include: > > "The thread may be waiting to enter the object's monitor, or in Object.wait waiting to reenter the monitor after being notified, interrupted, or timeout." Good suggestion, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1499360404 From alanb at openjdk.org Thu Feb 22 15:04:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Feb 2024 15:04:55 GMT Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> Message-ID: On Wed, 21 Feb 2024 10:28:49 GMT, Serguei Spitsyn wrote: > The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. > With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified. > > The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note. > > CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly > RN: [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly > > Testing: > - tested with the mach5 tiers 1-6 Are you planning to update ThreadReference::currentContendedMonitor method description too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17944#issuecomment-1959636693 From sspitsyn at openjdk.org Thu Feb 22 16:29:55 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 16:29:55 GMT Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly In-Reply-To: References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> Message-ID: On Thu, 22 Feb 2024 15:02:18 GMT, Alan Bateman wrote: > Are you planning to update ThreadReference::currentContendedMonitor method description too? Initially, I wanted to address it separately. But it is better to fix all together. I'll update my fix, the CSR and RN. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17944#issuecomment-1959810600 From sspitsyn at openjdk.org Thu Feb 22 18:53:19 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Feb 2024 18:53:19 GMT Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly [v2] In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com> Message-ID: > The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. > With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified. > > The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note. > > CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly > RN: [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly > > Testing: > - tested with the mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17944/files - new: https://git.openjdk.org/jdk/pull/17944/files/b8287a56..3ce67fa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17944.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944 PR: https://git.openjdk.org/jdk/pull/17944 From kbarrett at openjdk.org Thu Feb 22 19:57:20 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Feb 2024 19:57:20 GMT Subject: RFR: 8326524: Rename agent_common.h Message-ID: Please review this trivial change that renames the file test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to agent_common.hpp. The #include updates were performed mechanically, and builds would fail if there were mistakes. The copyright updates were similarly performed mechanically. All but a handful of the including files have already had their copyrights updated recently, likely as part of JDK-8324681. The only change to the renamed file is a copyright update, since no code changes were required. Testing: mach5 tier1 ------------- Commit messages: - update copyrights - rename agent_common.h -- no copyrights Changes: https://git.openjdk.org/jdk/pull/17970/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17970&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326524 Stats: 551 lines in 547 files changed: 0 ins; 0 del; 551 mod Patch: https://git.openjdk.org/jdk/pull/17970.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17970/head:pull/17970 PR: https://git.openjdk.org/jdk/pull/17970 From amenkov at openjdk.org Thu Feb 22 20:00:03 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 22 Feb 2024 20:00:03 GMT Subject: RFR: JDK-8326525: com/sun/tools/attach/BasicTests.java does not verify AgentLoadException case Message-ID: The change updates the test to throw an exception if expected AgentLoadException is not thrown ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/17971/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17971&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326525 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17971.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17971/head:pull/17971 PR: https://git.openjdk.org/jdk/pull/17971 From coleenp at openjdk.org Thu Feb 22 20:09:53 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 22 Feb 2024 20:09:53 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: <14OOmd4f-27eJD5WD1apJOCrYcDoG6guxPF3DYiDtZ0=.16b561c9-2b3f-44c3-9d7f-5b3bb192ebf1@github.com> On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 I have a suggestion that'll make this worth scrolling just once. test/hotspot/jtreg/vmTestbase/nsk/jvmti/Deallocate/dealloc001/dealloc001.cpp line 28: > 26: #include "jvmti.h" > 27: #include "agent_common.hpp" > 28: #include "JVMTITools.h" Why don't you change all of these together? It's the same or similar scrolling. ------------- PR Review: https://git.openjdk.org/jdk/pull/17970#pullrequestreview-1896852273 PR Review Comment: https://git.openjdk.org/jdk/pull/17970#discussion_r1499878024 From amenkov at openjdk.org Thu Feb 22 21:43:23 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 22 Feb 2024 21:43:23 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v3] In-Reply-To: References: Message-ID: > VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: > - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); > - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). > > before jdk21 if attach listener fails to load required library, it returned error (case 1) > from jdk21 attach listener always returns success (case 2) > Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. > > The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. > Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) > > Testing: > - test/jdk/com/sun/tools; > - tier1,tier2,tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17954/files - new: https://git.openjdk.org/jdk/pull/17954/files/0304bae2..dcb1db0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954 PR: https://git.openjdk.org/jdk/pull/17954 From cjplummer at openjdk.org Thu Feb 22 22:12:53 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Feb 2024 22:12:53 GMT Subject: RFR: JDK-8326525: com/sun/tools/attach/BasicTests.java does not verify AgentLoadException case In-Reply-To: References: Message-ID: <0tJqvair0M1vDocgdXgWCQQLdiOR8Gpenn3L6czhXFg=.bf844399-d2e0-467e-81be-2b1f02e73457@github.com> On Thu, 22 Feb 2024 19:46:58 GMT, Alex Menkov wrote: > The change updates the test to throw an exception if expected AgentLoadException is not thrown Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17971#pullrequestreview-1897048839 From cjplummer at openjdk.org Thu Feb 22 22:29:58 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Feb 2024 22:29:58 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 21:43:23 GMT, Alex Menkov wrote: >> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: >> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); >> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). >> >> before jdk21 if attach listener fails to load required library, it returned error (case 1) >> from jdk21 attach listener always returns success (case 2) >> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. >> >> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. >> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) >> >> Testing: >> - test/jdk/com/sun/tools; >> - tier1,tier2,tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback In invoke_Agent_OnAttach(), I think the second print_cr() should start with a space: st->print_cr("%s was not loaded.", agent->name()); if (*ebuf != '\0') { st->print_cr("%s", &ebuf[0]); } return false; Otherwise in the output you see the reason for the failure start right after the period: `com.sun.tools.attach.AgentLoadException: Failed to load agent library: FailedLoadAgentTestNotExists was not loaded.libFailedLoadAgentTestNotExists.so: cannot open shared object file: No such file or directory` Also, ebuf is of size 1024 and is getting truncated sometimes. See your macosx log files on mdash. This doesn't necessarily have to be fixed, but something to consider. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17954#issuecomment-1960431370 From amenkov at openjdk.org Thu Feb 22 23:27:54 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 22 Feb 2024 23:27:54 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:27:04 GMT, Chris Plummer wrote: > In invoke_Agent_OnAttach(), I think the second print_cr() should start with a space: > > ``` > st->print_cr("%s was not loaded.", agent->name()); > if (*ebuf != '\0') { > st->print_cr("%s", &ebuf[0]); > } > return false; > ``` > > Otherwise in the output you see the reason for the failure start right after the period: > > `com.sun.tools.attach.AgentLoadException: Failed to load agent library: FailedLoadAgentTestNotExists was not loaded.libFailedLoadAgentTestNotExists.so: cannot open shared object file: No such file or directory` It may be other messages in the outputStream (like "Dynamic agent loading is not enabled.") So I think it should be fixed in HotSpotVirtualMachine.readErrorMessage (it converts multi-line message to single string) by replacing CRs with spaces. > > Also, ebuf is of size 1024 and is getting truncated sometimes. See your macosx log files on mdash. This doesn't necessarily have to be fixed, but something to consider. I'll file a separate issue for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17954#issuecomment-1960504459 From amenkov at openjdk.org Thu Feb 22 23:31:16 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 22 Feb 2024 23:31:16 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v4] In-Reply-To: References: Message-ID: > VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: > - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); > - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). > > before jdk21 if attach listener fails to load required library, it returned error (case 1) > from jdk21 attach listener always returns success (case 2) > Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. > > The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. > Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) > > Testing: > - test/jdk/com/sun/tools; > - tier1,tier2,tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Fixed readErrorMessage() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17954/files - new: https://git.openjdk.org/jdk/pull/17954/files/dcb1db0d..66b24479 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954 PR: https://git.openjdk.org/jdk/pull/17954 From sspitsyn at openjdk.org Fri Feb 23 00:39:03 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Feb 2024 00:39:03 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 Looks good. I have a minor concern about the Copyright headers in 547 files. What is the ways to make sure they are updated? ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17970#pullrequestreview-1897217284 From amenkov at openjdk.org Fri Feb 23 01:32:54 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 23 Feb 2024 01:32:54 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 23:25:06 GMT, Alex Menkov wrote: > Also, ebuf is of size 1024 and is getting truncated sometimes. See your macosx log files on mdash. This doesn't necessarily have to be fixed, but something to consider. All other callers of os::dll_load() also use buffer of 1024 chars. Looks like dlerror() on macosx is very verbose. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17954#issuecomment-1960613948 From dlong at openjdk.org Fri Feb 23 02:09:55 2024 From: dlong at openjdk.org (Dean Long) Date: Fri, 23 Feb 2024 02:09:55 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 If we wanted to minimize changes, we could have agent_common.h include agent_common.hpp. Then we don't have to change all the .cpp files, which have other problems, like the includes not being sorted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17970#issuecomment-1960638558 From kbarrett at openjdk.org Fri Feb 23 04:11:53 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Feb 2024 04:11:53 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 00:36:43 GMT, Serguei Spitsyn wrote: > Looks good. I have a minor concern about the Copyright headers in 547 files. What is the ways to make sure they are updated? Here's the bash script I used: #!/usr/bin/env bash for f in `git diff master --name-only`; do sed -i \ -e "s/Copyright (c) ([12][0-9][0-9][0-9]), [0-9][0-9][0-9][0-9], Oracle/Copyright (c) \1, 2024, Oracle/" \ -e "s/Copyright (c) ([12][0-9][0-9][012356789]), Oracle/Copyright (c) \1, 2024, Oracle/" \ -e "s/Copyright (c) ([12][0-9][013456789]4), Oracle/Copyright (c) \1, 2024, Oracle/" $f; done The sed -e options are from Coleen. It found and updated the copyrights in a small number of files: test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnUnload/agentonunload001/agentonunload001.cpp test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/OnUnload/JvmtiTest/JvmtiTest.cpp test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/environment/JvmtiTest/JvmtiTest.cpp test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.cpp ------------- PR Comment: https://git.openjdk.org/jdk/pull/17970#issuecomment-1960706717 From kbarrett at openjdk.org Fri Feb 23 04:27:53 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Feb 2024 04:27:53 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 02:07:02 GMT, Dean Long wrote: > If we wanted to minimize changes, we could have agent_common.h include agent_common.hpp. Then we don't have to change all the .cpp files, which have other problems, like the includes not being sorted. The purpose of this exercise is to eliminate uses of NULL in C++ code in test/hotspot. Coleen already dealt with most of them. But she missed some because they were in files with a .h extension, so look like C files. However, (nearly?) all of them contain C++ code and would not compile with a C compiler. But there are a small number of actual C .h files. The renaming exercise is intended to leave us with a clearer separation of languages, so we can more easily search for misplaced NULLs. You are correct that renaming the offending .h files to .hpp and adding a corresponding forwarding .h file would have reduced the include churn. I feel like that just adds to what is already a somewhat confusing mess. And yes, there are lots of other style issues with many/most of these tests. They also use `extern "C"` blocks in "unusual" ways. I think test/hotspot/jtreg/vmTestbase/README.md is relevant to this discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17970#issuecomment-1960715448 From kbarrett at openjdk.org Fri Feb 23 04:33:53 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Feb 2024 04:33:53 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 I probably should have mentioned in the PR description that there's a tiny (one file) Oracle closed part of this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17970#issuecomment-1960718566 From kbarrett at openjdk.org Fri Feb 23 04:33:54 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Feb 2024 04:33:54 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: <14OOmd4f-27eJD5WD1apJOCrYcDoG6guxPF3DYiDtZ0=.16b561c9-2b3f-44c3-9d7f-5b3bb192ebf1@github.com> References: <14OOmd4f-27eJD5WD1apJOCrYcDoG6guxPF3DYiDtZ0=.16b561c9-2b3f-44c3-9d7f-5b3bb192ebf1@github.com> Message-ID: On Thu, 22 Feb 2024 20:06:50 GMT, Coleen Phillimore wrote: >> Please review this trivial change that renames the file >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to >> agent_common.hpp. >> >> The #include updates were performed mechanically, and builds would fail if >> there were mistakes. >> >> The copyright updates were similarly performed mechanically. All but a handful >> of the including files have already had their copyrights updated recently, >> likely as part of JDK-8324681. The only change to the renamed file is a >> copyright update, since no code changes were required. >> >> Testing: mach5 tier1 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/Deallocate/dealloc001/dealloc001.cpp line 28: > >> 26: #include "jvmti.h" >> 27: #include "agent_common.hpp" >> 28: #include "JVMTITools.h" > > Why don't you change all of these together? It's the same or similar scrolling. As I said in our private chat, I'll look at doing that for at least some of the remainder. I already had this one queued up, tested, and ready to submit the PR when you made that suggestion. But avoiding that scrolling is why I described how those updates were done. If you believe the (implicit) suggestion in the PR description, you don't need to look at them at all, and can just find the renamed file in the file list at the left in the review window (so much less scrolling) and go look at it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17970#discussion_r1500200028 From jwaters at openjdk.org Fri Feb 23 06:13:56 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 23 Feb 2024 06:13:56 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change This doesn't look trivial at all :P ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/17970#pullrequestreview-1897425509 From sjohanss at openjdk.org Fri Feb 23 08:04:55 2024 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 23 Feb 2024 08:04:55 GMT Subject: RFR: 8326065: Merge Space into ContiguousSpace In-Reply-To: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> References: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> Message-ID: On Fri, 16 Feb 2024 17:00:15 GMT, Albert Mingkun Yang wrote: > Merging a super class into its single sub class. > > Test: tier1-6 Looks good, feels like the files should change name as well. Now when there no longer is a `Space`. But maybe that's even better to do once we have moved `TenuredSpace` into Serial.? ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17891#pullrequestreview-1897558605 From kbarrett at openjdk.org Fri Feb 23 08:06:53 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Feb 2024 08:06:53 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 06:11:29 GMT, Julian Waters wrote: > > Please review this trivial change > > This doesn't look trivial at all :P While there are a lot of files being touched, the changes to all but one are purely mechanical, no thinking required. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17970#issuecomment-1960884119 From kevinw at openjdk.org Fri Feb 23 10:11:57 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Feb 2024 10:11:57 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v3] In-Reply-To: <-ncgmJ585uqNSp1vIbXfcDM4rNPmoESFlHLStOlkQXM=.3d1cef9e-bc5b-4239-9937-d04f88a8ecd2@github.com> References: <-ncgmJ585uqNSp1vIbXfcDM4rNPmoESFlHLStOlkQXM=.3d1cef9e-bc5b-4239-9937-d04f88a8ecd2@github.com> Message-ID: On Sat, 17 Feb 2024 02:41:20 GMT, Alex Menkov wrote: >> The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) >> >> Testing: tier1, tier2, tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > split test In the CSR you mention the two places we document the format. If this goes ahead, we should be updating them to be more specific, to declare that this field is not VM-independent, it has specific VM knowledge, so maybe for HPROF_GC_CLASS_DUMP: u4 instance size (in bytes) becomes: u4 instance size (in bytes, including VM header, padding) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1961049485 From ayang at openjdk.org Fri Feb 23 11:50:58 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 23 Feb 2024 11:50:58 GMT Subject: RFR: 8326065: Merge Space into ContiguousSpace In-Reply-To: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> References: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> Message-ID: On Fri, 16 Feb 2024 17:00:15 GMT, Albert Mingkun Yang wrote: > Merging a super class into its single sub class. > > Test: tier1-6 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17891#issuecomment-1961186277 From ayang at openjdk.org Fri Feb 23 11:50:58 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 23 Feb 2024 11:50:58 GMT Subject: Integrated: 8326065: Merge Space into ContiguousSpace In-Reply-To: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> References: <0TGeS_v2Ur13hcJEUxQSFxNEetrmeV8XjD33vxaDGqE=.3a47945d-3806-4922-b518-c12ff168c544@github.com> Message-ID: <3XMa6mfGiVpqYvK41apwZ2iKxbrmY1q2YFQTSC-ZCGM=.89688507-87e1-46b5-bb52-eb1abff079cb@github.com> On Fri, 16 Feb 2024 17:00:15 GMT, Albert Mingkun Yang wrote: > Merging a super class into its single sub class. > > Test: tier1-6 This pull request has now been integrated. Changeset: ef2d5c40 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/ef2d5c40c0d997ba1c5c7eaa50040e8757f06f36 Stats: 401 lines in 8 files changed: 50 ins; 313 del; 38 mod 8326065: Merge Space into ContiguousSpace Reviewed-by: cjplummer, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/17891 From sspitsyn at openjdk.org Fri Feb 23 12:05:58 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Feb 2024 12:05:58 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v4] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 23:31:16 GMT, Alex Menkov wrote: >> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: >> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); >> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). >> >> before jdk21 if attach listener fails to load required library, it returned error (case 1) >> from jdk21 attach listener always returns success (case 2) >> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. >> >> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. >> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) >> >> Testing: >> - test/jdk/com/sun/tools; >> - tier1,tier2,tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Fixed readErrorMessage() Thank you for the update. The fix looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17954#pullrequestreview-1897959055 From sspitsyn at openjdk.org Fri Feb 23 13:24:21 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Feb 2024 13:24:21 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v15] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: improved the ObjectMonitorUsage test to make it more elegant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/ef779169..716deae2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=13-14 Stats: 105 lines in 1 file changed: 39 ins; 44 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From ihse at openjdk.org Fri Feb 23 16:28:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Feb 2024 16:28:01 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution Message-ID: The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. ------------- Commit messages: - 8326583: Remove over-generalized DefineNativeToolchain solution Changes: https://git.openjdk.org/jdk/pull/17986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326583 Stats: 225 lines in 14 files changed: 55 ins; 137 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/17986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986 PR: https://git.openjdk.org/jdk/pull/17986 From ihse at openjdk.org Fri Feb 23 17:01:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Feb 2024 17:01:54 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. I have verified that there is no differences in the resulting output using COMPARE_BUILD, for the platforms in Oracle's CI: windows-x64,linux-x64,linux-aarch64,macosx-x64,macosx-aarch64, confirming that this is a pure build system refactoring. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1961679913 From cjplummer at openjdk.org Fri Feb 23 17:01:55 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Feb 2024 17:01:55 GMT Subject: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v4] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 23:31:16 GMT, Alex Menkov wrote: >> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: >> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); >> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). >> >> before jdk21 if attach listener fails to load required library, it returned error (case 1) >> from jdk21 attach listener always returns success (case 2) >> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. >> >> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. >> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) >> >> Testing: >> - test/jdk/com/sun/tools; >> - tier1,tier2,tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Fixed readErrorMessage() Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17954#pullrequestreview-1898562404 From sspitsyn at openjdk.org Fri Feb 23 17:46:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Feb 2024 17:46:08 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v16] In-Reply-To: References: Message-ID: <5gGbuzIvk8-lozRDGmJlr4G1cnrsyyUXMOBOG_VB3i4=.b5ee3bb3-fd1c-4639-9ca1-0a2c7c8dd19b@github.com> > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision: - fix potential sync gap in the test ObjectMonitorUsage - improve ObjectMonitorUsage test native agent output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/716deae2..fd507055 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=14-15 Stats: 146 lines in 2 files changed: 114 ins; 20 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From erikj at openjdk.org Fri Feb 23 18:19:53 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Feb 2024 18:19:53 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17986#pullrequestreview-1898688421 From sspitsyn at openjdk.org Fri Feb 23 18:40:10 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Feb 2024 18:40:10 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v17] In-Reply-To: References: Message-ID: > The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. > The function returns the following structure: > > > typedef struct { > jthread owner; > jint entry_count; > jint waiter_count; > jthread* waiters; > jint notify_waiter_count; > jthread* notify_waiters; > } jvmtiMonitorUsage; > > > The following four fields are defined this way: > > waiter_count [jint] The number of threads waiting to own this monitor > waiters [jthread*] The waiter_count waiting threads > notify_waiter_count [jint] The number of threads waiting to be notified by this monitor > notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified > > The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. > The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. > The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. > The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. > This update makes it right. > > The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. > > The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: > > jvmti/GetObjectMonitorUsage/objmonusage001 > jvmti/GetObjectMonitorUsage/objmonusage003 > > > The following JVMTI JCK tests have to be fixed to adopt to correct behavior: > > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html > vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html > > > > A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. > > Also, please see and review the related CSR: > [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage > > The Release-Note is: > [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage > > Testing: > - tested with mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fix a typo in libObjectMonitorUsage.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17680/files - new: https://git.openjdk.org/jdk/pull/17680/files/fd507055..091fd29c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680 PR: https://git.openjdk.org/jdk/pull/17680 From dlong at openjdk.org Fri Feb 23 19:10:54 2024 From: dlong at openjdk.org (Dean Long) Date: Fri, 23 Feb 2024 19:10:54 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17970#pullrequestreview-1898767675 From cjplummer at openjdk.org Fri Feb 23 19:11:13 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Feb 2024 19:11:13 GMT Subject: RFR: 8324868: debug agent does not properly handle interrupts of a virtual thread In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 19:06:59 GMT, Chris Plummer wrote: > Fix numerous debug agent issues and testing deficiencies related to Thread.interrupt(). As a first read you should look at the description in the CR. More details in first comment below. > > Also, this PR is dependent on the fix for [JDK-8325187](https://bugs.openjdk.org/browse/JDK-8325187). The test might generate GHA failures in the meantime. > > Tested with all svc tier1, tier2, and tier5 tests. If Thread.interrupt() is called on a thread that is currently in the debug agent handling a JVMTI event, it can result in a RawMonitorWait() call returning with JVMTI_ERROR_INTERRUPT. This can also happen if the interrupt was already pending when the JVMTI event came in. When this happens the debug agent sets the ThreadNode->pendingInterrupt flag and re-enters the RawMonitorWait(). When the debug agent is done dealing with the event, it calls threadControl_onEventHandlerExit(), which calls doPendingTasks(), which will call JVMTI InterruptThread() to reset the interrupt status of the thread. There were a few bugs in this code related to virtual threads. 1st issue is that the call to JVMTI InterruptThread() resulted in an upcall to the java Thread.interrupt() while while holding threadLock. Problems arise when during this upcall the debug agent is re-entered due to an event. The case I ran into was due to single stepping, which was enabled by the InterruptHangTest.java. When the debug agent is re-entered, it grabs the handlerLock. This creates a deadlock potential because it already holds the threadLock, and should be grabbing the handlerLock before the threadLock. An indeed a deadlock did happen because another thread had already grabbed the handlerLock and was blocked trying to grab the threadLock. My first attempt to fix this was to simply make threadControl_onEventHandlerExit() always grab both the threadLock and the handlerLock. Therefore when the debug agent was re-entered during the InterruptThread() call, it would already have both locks and not have a locking order issue. This seemed to work, but I didn't like the idea of the debug agent being re-entered with locks already held, so I reworked the code to no longer need the locks held during the InterruptThread() call. A 2nd issue was found in threadControl_interrupt(). It is called when the ThreadReference.Interrupt JDWP command is issued. If the thread is currently handling an event, it is suppose to set ThreadNode->pendingInterrupt so the interrupt can be raised after handling the event is complete. However, it was calling findThread(&runningThreads), which means it would always fail to find a virtual thread. This ended up not really being an issue, because it would just call InterruptThread() immediatly as a result. As it turns out this is ok even if the thread is already handling an event because as described above, the debug agent already has code in place for this (the RawMonitorWait() retry code). So rather than fix the findThread() call I just made it so this code now always calls InterruptThread(), even if the thread is currently handling an event. Note this is tested by the new InterruptHangTest.java "remote" mode, which uses ThreadReference.interrupt(). A 3rd issue was in threadControl_currentThread(), which is used by handleInterrupt() to decide if threadControl_setPendingInterrupt() should be called to setup the deferred resetting of the interrupt. The problem was that threadControl_currentThread() was using findThread(&runningThreads), which won't find virtual threads. As a result of this, threadControl_setPendingInterrupt() was never being called for virtual threads, so the interrupted was lost. It could have been fixed by using findRunningThread(), but I decided to just instead use JVMTI to get the current thread. A 4th issue was threadControl_setPendingInterrupt(), which actually has multiple issues itself. The first is the comment, which is dated and no longer correct, so I removed it. Related to that is the assert, which I wasn't sure why it wasn't being triggered for virtual threads. The threadControl_currentThread() issue above ended up being the reason. Once that was fixed, the assert was triggered and needed to be removed. The 3rd is another incorrect call to findThread(&runningThreads), which won't find virtual threads. This was fixed to instead use findRunningThread(), which will find virtual threads. I also removed the check for a NULL node and instead added an assert since it should always be found. The test has been reworked to have 3 modes now and do a much better job of testing. Read the long comment in the test for details. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17989#issuecomment-1961849739 From cjplummer at openjdk.org Fri Feb 23 19:11:13 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Feb 2024 19:11:13 GMT Subject: RFR: 8324868: debug agent does not properly handle interrupts of a virtual thread Message-ID: Fix numerous debug agent issues and testing deficiencies related to Thread.interrupt(). As a first read you should look at the description in the CR. More details in first comment below. Also, this PR is dependent on the fix for [JDK-8325187](https://bugs.openjdk.org/browse/JDK-8325187). The test might generate GHA failures in the meantime. Tested with all svc tier1, tier2, and tier5 tests. ------------- Commit messages: - Undo some test changes that were suppose to be temporary - Improved debug agent thread interrupt handling Changes: https://git.openjdk.org/jdk/pull/17989/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17989&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324868 Stats: 299 lines in 3 files changed: 173 ins; 62 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/17989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17989/head:pull/17989 PR: https://git.openjdk.org/jdk/pull/17989 From amenkov at openjdk.org Sat Feb 24 01:05:11 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 24 Feb 2024 01:05:11 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v3] In-Reply-To: References: <-ncgmJ585uqNSp1vIbXfcDM4rNPmoESFlHLStOlkQXM=.3d1cef9e-bc5b-4239-9937-d04f88a8ecd2@github.com> Message-ID: On Fri, 23 Feb 2024 10:08:49 GMT, Kevin Walls wrote: > In the CSR you mention the two places we document the format. If this goes ahead, we should be updating them to be more specific, to declare that this field is not VM-independent, it has specific VM knowledge, so maybe for HPROF_GC_CLASS_DUMP: > > u4 instance size (in bytes) becomes: u4 instance size (in bytes, including VM header, padding) I updated the CSR ------------- PR Comment: https://git.openjdk.org/jdk/pull/17855#issuecomment-1962189268 From sspitsyn at openjdk.org Sat Feb 24 04:12:54 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 24 Feb 2024 04:12:54 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v3] In-Reply-To: <-ncgmJ585uqNSp1vIbXfcDM4rNPmoESFlHLStOlkQXM=.3d1cef9e-bc5b-4239-9937-d04f88a8ecd2@github.com> References: <-ncgmJ585uqNSp1vIbXfcDM4rNPmoESFlHLStOlkQXM=.3d1cef9e-bc5b-4239-9937-d04f88a8ecd2@github.com> Message-ID: <4sCntVI65-gY7nIO5yA1Nc6kLx-YXdLXDzNiG-knNJQ=.19c97ca6-cd6f-4b90-9174-eed85b85e24f@github.com> On Sat, 17 Feb 2024 02:41:20 GMT, Alex Menkov wrote: >> The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) >> >> Testing: tier1, tier2, tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > split test src/hotspot/share/services/heapDumper.cpp line 1149: > 1147: DumperClassCacheTableEntry* cache_entry = class_cache->lookup_or_create(ik); > 1148: > 1149: u4 is = cache_entry->instance_size(); The old version had a check `(cache_entry != nullptr)` at line 1046. Is it not applicable anymore? Can the `cache_entry` be set to `nullptr` at this point? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17855#discussion_r1501339219 From sspitsyn at openjdk.org Sat Feb 24 04:41:00 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 24 Feb 2024 04:41:00 GMT Subject: RFR: JDK-8176520: Improve the accuracy of the instance size in hprof heap dumps [v3] In-Reply-To: <-ncgmJ585uqNSp1vIbXfcDM4rNPmoESFlHLStOlkQXM=.3d1cef9e-bc5b-4239-9937-d04f88a8ecd2@github.com> References: <-ncgmJ585uqNSp1vIbXfcDM4rNPmoESFlHLStOlkQXM=.3d1cef9e-bc5b-4239-9937-d04f88a8ecd2@github.com> Message-ID: On Sat, 17 Feb 2024 02:41:20 GMT, Alex Menkov wrote: >> The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) >> >> Testing: tier1, tier2, tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > split test The fix looks good in general. I've posted a question about the instance size verification. It applies to the SA test as well. test/hotspot/jtreg/serviceability/HeapDump/HeapDumpInstanceSize.java line 39: > 37: * @bug 8176520 > 38: * @summary Test that heap dumper reports correct instance size in HPROF_GC_CLASS_DUMP records > 39: * @requires vm.jvmti Q: Is the `vm.jvmti` really needed? test/hotspot/jtreg/serviceability/HeapDump/HeapDumpInstanceSize.java line 88: > 86: } else { > 87: // non-array should have >0 instance size > 88: if (instSize == 0) { This check is not that strong. How were the real instance sizes verified? Is it in the `HprofParser.parseAndVerify(fileDump)`? test/hotspot/jtreg/serviceability/sa/HeapDumpInstanceSize.java line 41: > 39: * @bug 8176520 > 40: * @summary Test that heap dumpers (VM and SA) report consistent instance size in HPROF_GC_CLASS_DUMP records > 41: * @requires vm.jvmti Q: Why is the `vm.jvmti` needed? ------------- PR Review: https://git.openjdk.org/jdk/pull/17855#pullrequestreview-1899212106 PR Review Comment: https://git.openjdk.org/jdk/pull/17855#discussion_r1501340467 PR Review Comment: https://git.openjdk.org/jdk/pull/17855#discussion_r1501342401 PR Review Comment: https://git.openjdk.org/jdk/pull/17855#discussion_r1501342661 From jwaters at openjdk.org Sat Feb 24 06:06:53 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 24 Feb 2024 06:06:53 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. !!! Not to be a party pooper, but this seems like it removes pretty some useful functionality from the build system. What if this is needed down the line? On the motivation of this change, TOOLCHAIN_LINK_CXX is pretty clear that the linker to be used is g++ instead of gcc for instance, while the new LANG parameter makes it look like SetupNativeCompilation only accepts and compiles C++ files if C++ is passed, and only C files if the new default of C is passed (For anyone looking in on this Pull Request who isn't familiar with the build system, it can compile a mix of both without issue). I'm not particularly sure this is a good idea, since a lot of flexibility seems to be lost with this change. I don't seem to see any simplification to SetupNativeCompilation either, maybe I'm missing something? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1962269640 From dchuyko at openjdk.org Sat Feb 24 11:22:17 2024 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Sat, 24 Feb 2024 11:22:17 GMT Subject: RFR: 8309271: A way to align already compiled methods with compiler directives [v26] In-Reply-To: References: Message-ID: > Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack. > > A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers. > > It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods). > > Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter. > > A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them. > > In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ... Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Deopt osr, cleanups - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - ... and 34 more: https://git.openjdk.org/jdk/compare/d10f277b...6d639ace ------------- Changes: https://git.openjdk.org/jdk/pull/14111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=25 Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/14111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111 PR: https://git.openjdk.org/jdk/pull/14111 From stuefe at openjdk.org Sun Feb 25 07:04:04 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 25 Feb 2024 07:04:04 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v25] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Tue, 20 Feb 2024 09:27:15 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > remove space Changes requested by stuefe (Reviewer). src/hotspot/os/aix/os_aix.cpp line 1167: > 1165: Load "libfilename.so" first, then load libfilename.a, on failure. > 1166: In OpenJ9, the libary with .so extension is loaded first and then .a extension, on failure. > 1167: */ Wrong block comment, but the comment itself is also off now. Suggestion: Suggestion: // Load library named // If filename matches .so, and loading fails, repeat with .a. src/hotspot/os/aix/os_aix.cpp line 1173: > 1171: char* const pointer_to_dot = strrchr(file_path, '.'); > 1172: char const *old_extension = ".so"; > 1173: char const *new_extension = ".a"; Suggestion: char* const file_path = strdup(filename); char* const pointer_to_dot = strrchr(file_path, '.'); const char old_extension[] = ".so"; const char new_extension[] = ".a"; STATIC_ASSERT(sizeof(old_exception) >= sizeof(new_exception)); and remove runtime-assert below src/hotspot/os/aix/os_aix.cpp line 1178: > 1176: FREE_C_HEAP_ARRAY(char, file_path); > 1177: return result; > 1178: } I would remove this whole section since it's a functional change not covered by the issue description and unnecessary for your fix. It may also be wrong: loading shared objects without extension may be perfectly valid. The extension is just a convention. src/hotspot/os/aix/os_aix.cpp line 1183: > 1181: // If the load fails,we try to reload by changing the extension to .a for .so files only. > 1182: // Shared object in .so format dont have braces, hence they get removed for archives with members. > 1183: if (result == nullptr) { Suggestion: if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) { src/hotspot/os/aix/os_aix.cpp line 1184: > 1182: // Shared object in .so format dont have braces, hence they get removed for archives with members. > 1183: if (result == nullptr) { > 1184: assert(strlen(new_extension) < strlen(old_extension), "New extension length must be less than existing one"); Can be removed if you do the STATIC_ASSERT suggested above. src/hotspot/os/aix/os_aix.cpp line 1186: > 1184: assert(strlen(new_extension) < strlen(old_extension), "New extension length must be less than existing one"); > 1185: if (strcmp(pointer_to_dot, old_extension) == 0) { > 1186: sprintf(pointer_to_dot, "%s", new_extension); Use os::snprintf, and limit output buffer by size of old extension. ------------- PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1899612274 PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501757595 PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501754431 PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501754774 PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501757736 PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501757772 PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501757844 From alanb at openjdk.org Sun Feb 25 10:55:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Feb 2024 10:55:58 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: References: Message-ID: <1LsvI6_C_bA6elUltTVR3xMY2Ro3vlUyp-ICt2Gzktw=.f20dc72a-7e46-4a3c-a7b1-20562cf0b215@github.com> On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote: > This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. > > The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` > > This addresses a category of NULL uses that wasn't dealt with by: > [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). > > Testing: > - TBD: run mach5 tiers1-3 JVMTI agents can be developed in C or C++. If I read this changes correctly, then this will replace all the NULLs in the generated spec with nullptr. I wonder if this needs some setup in the Introduction section, e.g. the Function Return Values subsection, to make this clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1962892766 From dholmes at openjdk.org Mon Feb 26 05:21:58 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Feb 2024 05:21:58 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: <1LsvI6_C_bA6elUltTVR3xMY2Ro3vlUyp-ICt2Gzktw=.f20dc72a-7e46-4a3c-a7b1-20562cf0b215@github.com> References: <1LsvI6_C_bA6elUltTVR3xMY2Ro3vlUyp-ICt2Gzktw=.f20dc72a-7e46-4a3c-a7b1-20562cf0b215@github.com> Message-ID: <01ZDNOpK76C_6ZjuMDOND0dxH-CxRD0bCXXcYi5I8EQ=.8eea7dff-0f88-488c-865d-db56dd963766@github.com> On Sun, 25 Feb 2024 10:53:20 GMT, Alan Bateman wrote: >> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. >> >> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` >> >> This addresses a category of NULL uses that wasn't dealt with by: >> [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). >> >> Testing: >> - TBD: run mach5 tiers1-3 > > JVMTI agents can be developed in C or C++. If I read this changes correctly, then this will replace all the NULLs in the generated spec with nullptr. I wonder if this needs some setup in the Introduction section, e.g. the Function Return Values subsection, to make this clear. As with the other NULL -> nullptr changes, when it involves text (as opposed to code) and we are discussing the general concept of nullness, then the word "null" should be used rather than the programmatic values `NULL` or `nullptr`. But if the source here is used to generated both the spec's functional descriptions and the code functions themselves, then we cannot make that distinction. I'm not sure this change was actually a good idea. At a minimum we need something like @AlanBateman suggests, something upfront to say that where the spec says `nullptr` it also means a C null pointer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1963338009 From ihse at openjdk.org Mon Feb 26 10:46:53 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 10:46:53 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: <_PhDAdwBOdLadnoyFkOp3P7i9SC7MkakgujqRJ5shNE=.54492764-dfb5-4a90-a47d-d0a8a7625cdc@github.com> On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. First some general remarks. The thing about generalization is that you need to take it in right enough doses -- too much is just as problematic as too little. You can represent any program with a Turing machine that can read or write, and move a head back and forth. That is extremely general, and completely hopeless to program in. The right amount of generalization is reached when it helps you express the underlying ideas in a easy-to-understand way. If you got duplication, then it means something needs to be more generalized. But if you have a general solution that is only ever used in a single way, then you have over-generalization. Secondly, trust the VCS. Keeping code around since it might be "needed down the line" is a very bad reason. If we will need it again, we can restore it from the history. My experience is that these things practically never happens -- even if you need something similar in the future, the requirements are almost always different enough that the old system did not work anyway. And now over to more specific comments about this patch. There was a historic need for this function. When it was created, we started a new build system from the ground up to consolidate a myriad of different ways to build parts of the product. There were no good standardized toolchain, and we had a requirement to really handle different toolchains. Then during the years we have chipped away at all the odds bits and pieces, until the entire build uses (basically) the same toolchain -- the only difference is the linker argument. And, of course, the orthogonal question if we're targeting the build machine or the target machine, when cross-compiling. This is a very clear concept in the rest of the build system, but it was diffused in the toolchain profiles by making it look like we just have another "profile", like it was another version of gcc. So in this PR we replace a very general idea of a "profile" with two distinct options that we really care about -- what platform to target, and how we call the linker. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1963821493 From ihse at openjdk.org Mon Feb 26 10:51:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 10:51:54 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. I could have chosen to name the `LANG` argument e.g. `LINKER_LANG`. If you insist, I can go back and rename it like this also. But there was a reason I chose the more general `LANG`, and that is because we have other unresolved issues regarding C vs C++ in the build. We don't handle CFLAGS vs CXXFLAGS very well, and we have several convoluted fixes (that just smells "black magic") to get the build to work. My instinct is that these are highly correlated to the choice of linker -- basically, in the old build system, there were a difference between C-libs anc C++-libs that were not properly carried over to the new build system. My intention is to continue this work by aligning flags etc with this property as well. But this is future work, so one could argue that with just this patch, the name `LANG` is overly broad. I thought it was okay, in the light of future development, and the wish to keep argument names succinct, but if you object I can rename it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1963835032 From sroy at openjdk.org Mon Feb 26 11:24:13 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 26 Feb 2024 11:24:13 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v26] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/664e41a4..1943445d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=24-25 Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From sroy at openjdk.org Mon Feb 26 11:29:02 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 26 Feb 2024 11:29:02 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v25] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Sun, 25 Feb 2024 06:32:20 GMT, Thomas Stuefe wrote: >> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: >> >> remove space > > src/hotspot/os/aix/os_aix.cpp line 1173: > >> 1171: char* const pointer_to_dot = strrchr(file_path, '.'); >> 1172: char const *old_extension = ".so"; >> 1173: char const *new_extension = ".a"; > > Suggestion: > > char* const file_path = strdup(filename); > char* const pointer_to_dot = strrchr(file_path, '.'); > const char old_extension[] = ".so"; > const char new_extension[] = ".a"; > STATIC_ASSERT(sizeof(old_exception) >= sizeof(new_exception)); > > and remove runtime-assert below @tstuefe done. Anyreason why we use [] instead of the pointer. Doesn't [] convert into *(baseaddress) ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1502454196 From coleenp at openjdk.org Mon Feb 26 13:48:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 26 Feb 2024 13:48:58 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 ok, I don't want to hold this up. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17970#pullrequestreview-1900922282 From coleenp at openjdk.org Mon Feb 26 13:48:59 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 26 Feb 2024 13:48:59 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: <14OOmd4f-27eJD5WD1apJOCrYcDoG6guxPF3DYiDtZ0=.16b561c9-2b3f-44c3-9d7f-5b3bb192ebf1@github.com> Message-ID: On Fri, 23 Feb 2024 04:29:47 GMT, Kim Barrett wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/Deallocate/dealloc001/dealloc001.cpp line 28: >> >>> 26: #include "jvmti.h" >>> 27: #include "agent_common.hpp" >>> 28: #include "JVMTITools.h" >> >> Why don't you change all of these together? It's the same or similar scrolling. > > As I said in our private chat, I'll look at doing that for at least some of the remainder. I already had this one > queued up, tested, and ready to submit the PR when you made that suggestion. But avoiding that scrolling > is why I described how those updates were done. If you believe the (implicit) suggestion in the PR description, > you don't need to look at them at all, and can just find the renamed file in the file list at the left in the review > window (so much less scrolling) and go look at it. Sure, but can you do the rest at the same time since they're in mostly the same files? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17970#discussion_r1502640501 From jpai at openjdk.org Mon Feb 26 15:10:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Feb 2024 15:10:31 GMT Subject: RFR: 8321971: Improve the user name detection logic in perfMemory get_user_name_slow [v3] In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 07:29:07 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to improve the code in `get_user_name_slow` function, which is used to identify the target JVM owner's user name? This addresses https://bugs.openjdk.org/browse/JDK-8321971. >> >> As noted in that JBS issue, in its current form, the nested loop ends up iterating over the directory contents of `hsperfdata_xxx` directory and then for each iteration it checks if the name of the entry matches the pid. This iteration shouldn't be needed and instead one could look for a file named `` within that directory. >> >> No new test has been added, given the nature of this change. Existing tier1, tier2, tier3 and svc_tools tests pass with this change on Linux, Windows and macosx. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - remove redundant if block > - merge latest from master branch > - David's review comments - reduce if blocks and release the array outside if block > - David's review comment - punctuation > - 8321971: Improve the user name detection logic in perfMemory get_user_name_slow Hello Johan, thank you for that input and sorry about the delay in responding. I got side tracked with a few other things. I plan to refresh this PR and address the comments, this week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17104#issuecomment-1964357753 From ihse at openjdk.org Mon Feb 26 15:57:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 15:57:03 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v2] In-Reply-To: References: Message-ID: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Reword "lib" comment to fit in better - Merge branch 'master' into remove-toolchain-define - 8326583: Remove over-generalized DefineNativeToolchain solution ------------- Changes: https://git.openjdk.org/jdk/pull/17986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=01 Stats: 231 lines in 14 files changed: 58 ins; 142 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/17986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986 PR: https://git.openjdk.org/jdk/pull/17986 From dchuyko at openjdk.org Mon Feb 26 20:08:46 2024 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Mon, 26 Feb 2024 20:08:46 GMT Subject: RFR: 8309271: A way to align already compiled methods with compiler directives [v26] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 11:22:17 GMT, Dmitry Chuyko wrote: >> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack. >> >> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers. >> >> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods). >> >> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter. >> >> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them. >> >> In addition, a new diagnostic command `Compiler.replace_directives... > > Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Deopt osr, cleanups > - Merge branch 'openjdk:master' into compiler-directives-force-update > - Merge branch 'openjdk:master' into compiler-directives-force-update > - ... and 34 more: https://git.openjdk.org/jdk/compare/d10f277b...6d639ace As this is an extension of the existing compiler control mechanism. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14111#issuecomment-1965157823 From ihse at openjdk.org Mon Feb 26 20:21:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 20:21:55 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Rename LANG to LINK_TYPE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17986/files - new: https://git.openjdk.org/jdk/pull/17986/files/f8a18690..5f446abd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=01-02 Stats: 27 lines in 13 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/17986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986 PR: https://git.openjdk.org/jdk/pull/17986 From ihse at openjdk.org Mon Feb 26 20:21:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 20:21:55 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: <2eorUGW4rI8MmbcbMAHrIHCm8cetjtaG87C6dyD_UgQ=.75c5ae8c-8ff9-4d0b-8031-66f51baffbbc@github.com> On Sat, 24 Feb 2024 06:04:40 GMT, Julian Waters wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > !!! > > Not to be a party pooper, but this seems like it removes pretty some useful functionality from the build system. What if this is needed down the line? On the motivation of this change, TOOLCHAIN_LINK_CXX is pretty clear that the linker to be used is g++ instead of gcc for instance, while the new LANG parameter makes it look like SetupNativeCompilation only accepts and compiles C++ files if C++ is passed, and only C files if the new default of C is passed (For anyone looking in on this Pull Request who isn't familiar with the build system, it can compile a mix of both without issue). I'm not particularly sure this is a good idea, since a lot of flexibility seems to be lost with this change. I don't seem to see any simplification to SetupNativeCompilation either, maybe I'm missing something? I renamed LANG to LINK_TYPE, to not make it overly general. @TheShermanTanker Are you okay with this patch now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965176131 From jiangli at openjdk.org Mon Feb 26 20:25:52 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 20:25:52 GMT Subject: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function Message-ID: Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. ------------- Commit messages: - Make closeDescriptors() as static function in src/java.base/unix/native/libjava/childproc.c and src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c. Changes: https://git.openjdk.org/jdk/pull/18013/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18013&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326433 Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18013/head:pull/18013 PR: https://git.openjdk.org/jdk/pull/18013 From cjplummer at openjdk.org Mon Feb 26 20:43:45 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 26 Feb 2024 20:43:45 GMT Subject: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote: > Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. src/java.base/unix/native/libjava/childproc.h line 134: > 132: int closeSafely(int fd); > 133: int isAsciiDigit(char c); > 134: int closeDescriptors(void); It seems that most of the APIs in this file should be static. I don't think you should selectively deal with just one of them because of the conflict. Since this ends up being a more involved change, and is in a different component than the jdwp change, it should probably have a separate PR. src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 65: > 63: // by this function. This function returns 0 on failure > 64: // and 1 on success. > 65: static int I think you should also make forkedChildProcess static. It was added at the same time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503271560 PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503268736 From jiangli at openjdk.org Mon Feb 26 22:17:44 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 22:17:44 GMT Subject: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function In-Reply-To: References: Message-ID: <98_cLDcnNTDPzP2XGeGaGvHaafDylPmPL5BXEjOBaNk=.04a2af67-002f-4032-a020-5abd15321eba@github.com> On Mon, 26 Feb 2024 20:40:52 GMT, Chris Plummer wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. > > src/java.base/unix/native/libjava/childproc.h line 134: > >> 132: int closeSafely(int fd); >> 133: int isAsciiDigit(char c); >> 134: int closeDescriptors(void); > > It seems that most of the APIs in this file should be static. I don't think you should selectively deal with just one of them because of the conflict. Since this ends up being a more involved change, and is in a different component than the jdwp change, it should probably have a separate PR. @plummercj thanks for looking into this! Sounds good to make the additional local functions static in these files. Perhaps we can use two different FRs. I'll make the current one to handle the ones in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503379848 From sspitsyn at openjdk.org Mon Feb 26 22:54:46 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 26 Feb 2024 22:54:46 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote: > This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. > > The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` > > This addresses a category of NULL uses that wasn't dealt with by: > [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). > > Testing: > - TBD: run mach5 tiers1-3 Now, we this section: Function Return Values JVM TI functions always return an [error code](http://100.110.26.5:8080/view/loom/job/loom-fibers-branch-build/lastSuccessfulBuild/artifact/loom/build/linux-x64/images/docs/specs/jvmti.html#ErrorSection) via the [jvmtiError](http://100.110.26.5:8080/view/loom/job/loom-fibers-branch-build/lastSuccessfulBuild/artifact/loom/build/linux-x64/images/docs/specs/jvmti.html#jvmtiError) function return value. Some functions can return additional values through pointers provided by the calling function. In some cases, JVM TI functions allocate memory that your program must explicitly deallocate. This is indicated in the individual JVM TI function descriptions. Empty lists, arrays, sequences, etc are returned as `nullptr`. In the event that the JVM TI function encounters an error (any return value other than `JVMTI_ERROR_NONE`) the values of memory referenced by argument pointers is undefined, but no memory will have been allocated and no global references will have been allocated. If the error occurs because of invalid input, no action will have occurred. The `nullptr` is mentioned here. As I understand from the Alan's and David's comments above we want to clarify what does it mean for C/C++ code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1965473360 From jiangli at openjdk.org Mon Feb 26 22:55:06 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 22:55:06 GMT Subject: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function [v2] In-Reply-To: References: Message-ID: > Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: - Address plummercj's comment and make forkedChildProcess static. - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18013/files - new: https://git.openjdk.org/jdk/pull/18013/files/bb9e2791..3816d315 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18013&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18013&range=00-01 Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18013/head:pull/18013 PR: https://git.openjdk.org/jdk/pull/18013 From jiangli at openjdk.org Mon Feb 26 22:58:43 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 22:58:43 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: <98_cLDcnNTDPzP2XGeGaGvHaafDylPmPL5BXEjOBaNk=.04a2af67-002f-4032-a020-5abd15321eba@github.com> References: <98_cLDcnNTDPzP2XGeGaGvHaafDylPmPL5BXEjOBaNk=.04a2af67-002f-4032-a020-5abd15321eba@github.com> Message-ID: On Mon, 26 Feb 2024 22:15:00 GMT, Jiangli Zhou wrote: >> src/java.base/unix/native/libjava/childproc.h line 134: >> >>> 132: int closeSafely(int fd); >>> 133: int isAsciiDigit(char c); >>> 134: int closeDescriptors(void); >> >> It seems that most of the APIs in this file should be static. I don't think you should selectively deal with just one of them because of the conflict. Since this ends up being a more involved change, and is in a different component than the jdwp change, it should probably have a separate PR. > > @plummercj thanks for looking into this! Sounds good to make the additional local functions static in these files. Perhaps we can use two different FRs. I'll make the current one to handle the ones in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c. Filed https://bugs.openjdk.org/browse/JDK-8326714. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503414392 From jiangli at openjdk.org Mon Feb 26 22:58:44 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 22:58:44 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: <2XXTCSfcAFMbMU0_f5i-dxfuga6rONV-ISqR0pptHzE=.06d2a47e-0b9a-4085-94cf-bc4d63019395@github.com> On Mon, 26 Feb 2024 20:37:45 GMT, Chris Plummer wrote: >> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address plummercj's comment and make forkedChildProcess static. >> - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. > > src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 65: > >> 63: // by this function. This function returns 0 on failure >> 64: // and 1 on success. >> 65: static int > > I think you should also make forkedChildProcess static. It was added at the same time. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503414683 From sspitsyn at openjdk.org Mon Feb 26 23:05:47 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 26 Feb 2024 23:05:47 GMT Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote: > This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`. > > The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build//variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` > > This addresses a category of NULL uses that wasn't dealt with by: > [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). > > Testing: > - TBD: run mach5 tiers1-3 Filed new Enhancement: [8326716](https://bugs.openjdk.org/browse/JDK-8326716): JVMTI spec: clarify what nullptr means for C/C++ developers ------------- PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1965485369 From amenkov at openjdk.org Mon Feb 26 23:21:52 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 26 Feb 2024 23:21:52 GMT Subject: Integrated: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 21:13:36 GMT, Alex Menkov wrote: > VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases: > - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute); > - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message). > > before jdk21 if attach listener fails to load required library, it returned error (case 1) > from jdk21 attach listener always returns success (case 2) > Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details. > > The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message. > Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code) > > Testing: > - test/jdk/com/sun/tools; > - tier1,tier2,tier5-svc This pull request has now been integrated. Changeset: fc67c2b4 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/fc67c2b4f17216d4adcc0825d0f378ae4f150025 Stats: 150 lines in 6 files changed: 109 ins; 16 del; 25 mod 8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/17954 From cjplummer at openjdk.org Mon Feb 26 23:52:44 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 26 Feb 2024 23:52:44 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. > > Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: > > - Address plummercj's comment and make forkedChildProcess static. > - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18013#pullrequestreview-1902255565 From jiangli at openjdk.org Mon Feb 26 23:59:45 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 23:59:45 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 23:50:11 GMT, Chris Plummer wrote: > Looks good. Thanks for the quick review, @plummercj. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18013#issuecomment-1965539618 From lmesnik at openjdk.org Tue Feb 27 00:31:45 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Feb 2024 00:31:45 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17970#pullrequestreview-1902294366 From sspitsyn at openjdk.org Tue Feb 27 00:37:46 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Feb 2024 00:37:46 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. > > Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: > > - Address plummercj's comment and make forkedChildProcess static. > - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18013#pullrequestreview-1902299044 From sspitsyn at openjdk.org Tue Feb 27 01:35:44 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Feb 2024 01:35:44 GMT Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug information In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com> Message-ID: On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote: > Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". > > Not recommended for live production use. Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools. Kevin, thank you for working on this! I've posted several comments/questions. src/hotspot/share/services/diagnosticCommand.cpp line 1200: > 1198: void VMDebugDCmd::find() { > 1199: if (!_arg1.has_value()) { > 1200: output()->print_cr("missing argument"); I'm thinking if it would be useful to tell what arguments are expected? This is for all cases where the `"missing argument"` message is returned. src/hotspot/share/services/diagnosticCommand.cpp line 1245: > 1243: } > 1244: } else if (strcmp("find", _subcommand.value()) == 0) { > 1245: if (!UnlockDiagnosticVMOptions) { Would it make sense to require enabling `UnlockDiagnosticVMOptions` for all sub-commands, so that it is clear this is not for live production use? ------------- PR Review: https://git.openjdk.org/jdk/pull/17655#pullrequestreview-1902349676 PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1503520152 PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1503518811 From jiangli at openjdk.org Tue Feb 27 01:36:47 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Feb 2024 01:36:47 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 00:34:49 GMT, Serguei Spitsyn wrote: >> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address plummercj's comment and make forkedChildProcess static. >> - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. > > Marked as reviewed by sspitsyn (Reviewer). Thanks for the review, @sspitsyn. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18013#issuecomment-1965631861 From jiangli at openjdk.org Tue Feb 27 01:36:48 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Feb 2024 01:36:48 GMT Subject: Integrated: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote: > Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. This pull request has now been integrated. Changeset: 0901dede Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/0901dedefe16afa3f7222723b3fec7a22d9df675 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/18013 From duke at openjdk.org Tue Feb 27 02:09:48 2024 From: duke at openjdk.org (Taizo Kurashige) Date: Tue, 27 Feb 2024 02:09:48 GMT Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump [v3] In-Reply-To: References: Message-ID: On Tue, 26 Dec 2023 14:15:17 GMT, Taizo Kurashige wrote: >> Hi, >> >> I fixed the typos for JFR.start and JFR.dump. >> Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. >> >> I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. >> >> Could someone please review it? > > Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision: > > 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump Could someone please review this PR? (Or will the review be done after https://bugs.openjdk.org/browse/JDK-8324089 is resolved?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16413#issuecomment-1965659547 From dholmes at openjdk.org Tue Feb 27 05:41:47 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Feb 2024 05:41:47 GMT Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump [v3] In-Reply-To: References: Message-ID: On Tue, 26 Dec 2023 14:15:17 GMT, Taizo Kurashige wrote: >> Hi, >> >> I fixed the typos for JFR.start and JFR.dump. >> Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. >> >> I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. >> >> Could someone please review it? > > Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision: > > 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump These changes seem fine to me. Hopefully @egahlin can also approve. BTW please merge your branch with master so that it is up to date. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16413#pullrequestreview-1902559381 PR Comment: https://git.openjdk.org/jdk/pull/16413#issuecomment-1965825683 From stuefe at openjdk.org Tue Feb 27 06:01:51 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 27 Feb 2024 06:01:51 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v26] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: <8tlU2NkIBMWNzit84PSd8Oo8QsiD92EKw5auHY0nkro=.0ecc1cd5-d98a-4239-afd8-6163f785bc38@github.com> On Mon, 26 Feb 2024 11:24:13 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Okay ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1902581556 From jkern at openjdk.org Tue Feb 27 07:03:51 2024 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 27 Feb 2024 07:03:51 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v26] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Mon, 26 Feb 2024 11:24:13 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/hotspot/os/aix/os_aix.cpp line 1175: > 1173: // Shared object in .so format dont have braces, hence they get removed for archives with members. > 1174: if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) { > 1175: if (strcmp(pointer_to_dot, old_extension) == 0) { Can you please remove this redundancy? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503728978 From jwaters at openjdk.org Tue Feb 27 07:38:43 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 07:38:43 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Rename LANG to LINK_TYPE Thanks for the run down on the history of the build system! I'm sorry it took me a day to respond, I must have missed this in my inbox while going over the GitHub activity of the day. Given that the function was meant for the older build system, it now seems reasonable to replace it with this newer solution. In the worst case scenario, a backout is possible, as was suggested. I would have said that LANG is an ok name and that there was no need to rename it to LINK_TYPE after the context given and the knowledge that future work was planned for it, had I read this earlier though :( This is also the first time I've ever had an objection to a Pull Request. Feels weird, really ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965949353 From sroy at openjdk.org Tue Feb 27 07:48:00 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 27 Feb 2024 07:48:00 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: remove redundant logic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/1943445d..57914589 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=25-26 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From sroy at openjdk.org Tue Feb 27 07:57:49 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 27 Feb 2024 07:57:49 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Tue, 27 Feb 2024 07:48:00 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant logic Thank you everyone for your inputs, It was great learning from all of them. I understood about secure coding guidelines in practice, which was a great experience. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1965971937 From duke at openjdk.org Tue Feb 27 08:06:18 2024 From: duke at openjdk.org (Taizo Kurashige) Date: Tue, 27 Feb 2024 08:06:18 GMT Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump [v4] In-Reply-To: References: Message-ID: <2QFRRgSpgP-IjTIj62wGFN5GcvMRsSvA_ubqzbb5_lI=.39bcf918-94c5-45ee-a115-e765f6139b25@github.com> > Hi, > > I fixed the typos for JFR.start and JFR.dump. > Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. > > I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. > > Could someone please review it? Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8313710 - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16413/files - new: https://git.openjdk.org/jdk/pull/16413/files/5fe59b39..25b64b56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16413&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16413&range=02-03 Stats: 952317 lines in 8146 files changed: 263136 ins; 580602 del; 108579 mod Patch: https://git.openjdk.org/jdk/pull/16413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16413/head:pull/16413 PR: https://git.openjdk.org/jdk/pull/16413 From duke at openjdk.org Tue Feb 27 08:09:53 2024 From: duke at openjdk.org (Taizo Kurashige) Date: Tue, 27 Feb 2024 08:09:53 GMT Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump [v4] In-Reply-To: <2QFRRgSpgP-IjTIj62wGFN5GcvMRsSvA_ubqzbb5_lI=.39bcf918-94c5-45ee-a115-e765f6139b25@github.com> References: <2QFRRgSpgP-IjTIj62wGFN5GcvMRsSvA_ubqzbb5_lI=.39bcf918-94c5-45ee-a115-e765f6139b25@github.com> Message-ID: On Tue, 27 Feb 2024 08:06:18 GMT, Taizo Kurashige wrote: >> Hi, >> >> I fixed the typos for JFR.start and JFR.dump. >> Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. >> >> I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. >> >> Could someone please review it? > > Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8313710 > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump I merged my branch with master. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16413#issuecomment-1965991239 From djelinski at openjdk.org Tue Feb 27 08:10:44 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 27 Feb 2024 08:10:44 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Rename LANG to LINK_TYPE can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is `gcc`; I searched for the differences, and the only thing I could find is that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could explicitly add these options, and use gcc everywhere. See: https://stackoverflow.com/a/172592 https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965991536 From jwaters at openjdk.org Tue Feb 27 08:17:46 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 08:17:46 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 08:07:38 GMT, Daniel Jeli?ski wrote: > can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is `gcc`; I searched for the differences, and the only thing I could find is that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could explicitly add these options, and use gcc everywhere. > > See: https://stackoverflow.com/a/172592 https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html I don't think that's a good idea, the differences between the gcc and g++ drivers are supposed to be (opaque) implementation details. Doing so would make us dependent on internal mechanisms of gcc subject to change between versions and would make bugfixing hard to do if such a change really happened and the linker command line got messed up as a result (This likely would impact clang too, unless I am mistaken?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966002485 From sroy at openjdk.org Tue Feb 27 08:31:15 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 27 Feb 2024 08:31:15 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v28] In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: indendt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/57914589..55090448 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=26-27 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604 From mdoerr at openjdk.org Tue Feb 27 08:31:15 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 27 Feb 2024 08:31:15 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Tue, 27 Feb 2024 07:48:00 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. >> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant logic src/hotspot/os/aix/os_aix.cpp line 1176: > 1174: if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) { > 1175: snprintf(pointer_to_dot, sizeof(old_extension), "%s", new_extension); > 1176: result = dll_load_library(file_path, ebuf, ebuflen); You should have adapted the indentation, too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503817600 From sroy at openjdk.org Tue Feb 27 08:31:15 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 27 Feb 2024 08:31:15 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27] In-Reply-To: References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: <9WIpKnZsaZFkbXwAjKQvwmngSuU7WvhV2LY2mHJ-LN0=.10e88c8f-d1b8-4edb-8b75-204bcdb9ebb4@github.com> On Tue, 27 Feb 2024 08:22:21 GMT, Martin Doerr wrote: >> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: >> >> remove redundant logic > > src/hotspot/os/aix/os_aix.cpp line 1176: > >> 1174: if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) { >> 1175: snprintf(pointer_to_dot, sizeof(old_extension), "%s", new_extension); >> 1176: result = dll_load_library(file_path, ebuf, ebuflen); > > You should have adapted the indentation, too. Which indentation ? @TheRealMDoerr adapted ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503820212 PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503824233 From sroy at openjdk.org Tue Feb 27 08:31:15 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 27 Feb 2024 08:31:15 GMT Subject: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27] In-Reply-To: <9WIpKnZsaZFkbXwAjKQvwmngSuU7WvhV2LY2mHJ-LN0=.10e88c8f-d1b8-4edb-8b75-204bcdb9ebb4@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> <9WIpKnZsaZFkbXwAjKQvwmngSuU7WvhV2LY2mHJ-LN0=.10e88c8f-d1b8-4edb-8b75-204bcdb9ebb4@github.com> Message-ID: <3Ijn-7dIJ9bNeJSj_YC1nZMLk5uuiigLhfIXBYngovY=.e15eb974-9144-4e28-8f9f-932b1c26d1e3@github.com> On Tue, 27 Feb 2024 08:23:58 GMT, Suchismith Roy wrote: >> src/hotspot/os/aix/os_aix.cpp line 1176: >> >>> 1174: if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) { >>> 1175: snprintf(pointer_to_dot, sizeof(old_extension), "%s", new_extension); >>> 1176: result = dll_load_library(file_path, ebuf, ebuflen); >> >> You should have adapted the indentation, too. > > Which indentation ? oh! to reduce the spaces ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503821531 From jwaters at openjdk.org Tue Feb 27 08:32:45 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 08:32:45 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Rename LANG to LINK_TYPE Just a small question by the way: All those new parameters to SetupNativeCompilation, were they always there and the comments about them were just missing from the documentation about the function? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966025499 From sroy at openjdk.org Tue Feb 27 09:19:01 2024 From: sroy at openjdk.org (Suchismith Roy) Date: Tue, 27 Feb 2024 09:19:01 GMT Subject: Integrated: JDK-8320005 : Allow loading of shared objects with .a extension on AIX In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com> Message-ID: On Fri, 10 Nov 2023 12:28:46 GMT, Suchismith Roy wrote: > J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX. > Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails. This pull request has now been integrated. Changeset: e85355ad Author: Suchismith Roy Committer: Martin Doerr URL: https://git.openjdk.org/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab Stats: 22 lines in 1 file changed: 20 ins; 1 del; 1 mod 8320005: Allow loading of shared objects with .a extension on AIX Reviewed-by: amitkumar, stuefe, jkern, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/16604 From egahlin at openjdk.org Tue Feb 27 09:47:49 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 27 Feb 2024 09:47:49 GMT Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump [v4] In-Reply-To: <2QFRRgSpgP-IjTIj62wGFN5GcvMRsSvA_ubqzbb5_lI=.39bcf918-94c5-45ee-a115-e765f6139b25@github.com> References: <2QFRRgSpgP-IjTIj62wGFN5GcvMRsSvA_ubqzbb5_lI=.39bcf918-94c5-45ee-a115-e765f6139b25@github.com> Message-ID: On Tue, 27 Feb 2024 08:06:18 GMT, Taizo Kurashige wrote: >> Hi, >> >> I fixed the typos for JFR.start and JFR.dump. >> Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. >> >> I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. >> >> Could someone please review it? > > Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8313710 > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump Looks good. Thanks for fixing this. I can sponsor the change. ------------- Marked as reviewed by egahlin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16413#pullrequestreview-1903021556 From kbarrett at openjdk.org Tue Feb 27 10:30:04 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Feb 2024 10:30:04 GMT Subject: RFR: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 Thanks all for reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17970#issuecomment-1966237067 From kbarrett at openjdk.org Tue Feb 27 10:30:05 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Feb 2024 10:30:05 GMT Subject: Integrated: 8326524: Rename agent_common.h In-Reply-To: References: Message-ID: <-2XzQrNWQ8T1EJYrNXJ9O-D5H9PlGyKvBaZq4EJ8K80=.e9bf7578-77f3-46f8-9d1e-d15e3c4b18f7@github.com> On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote: > Please review this trivial change that renames the file > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to > agent_common.hpp. > > The #include updates were performed mechanically, and builds would fail if > there were mistakes. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. The only change to the renamed file is a > copyright update, since no code changes were required. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: d482c1af Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/d482c1af28cacd60cc05fe3f975a00a0c68c72b7 Stats: 551 lines in 547 files changed: 0 ins; 0 del; 551 mod 8326524: Rename agent_common.h Reviewed-by: coleenp, sspitsyn, jwaters, dlong, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/17970 From duke at openjdk.org Tue Feb 27 10:35:59 2024 From: duke at openjdk.org (Taizo Kurashige) Date: Tue, 27 Feb 2024 10:35:59 GMT Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump [v4] In-Reply-To: <2QFRRgSpgP-IjTIj62wGFN5GcvMRsSvA_ubqzbb5_lI=.39bcf918-94c5-45ee-a115-e765f6139b25@github.com> References: <2QFRRgSpgP-IjTIj62wGFN5GcvMRsSvA_ubqzbb5_lI=.39bcf918-94c5-45ee-a115-e765f6139b25@github.com> Message-ID: On Tue, 27 Feb 2024 08:06:18 GMT, Taizo Kurashige wrote: >> Hi, >> >> I fixed the typos for JFR.start and JFR.dump. >> Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. >> >> I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. >> >> Could someone please review it? > > Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8313710 > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump > - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16413#issuecomment-1966250736 From duke at openjdk.org Tue Feb 27 10:42:54 2024 From: duke at openjdk.org (Taizo Kurashige) Date: Tue, 27 Feb 2024 10:42:54 GMT Subject: Integrated: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 08:46:08 GMT, Taizo Kurashige wrote: > Hi, > > I fixed the typos for JFR.start and JFR.dump. > Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. > > I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. > > Could someone please review it? This pull request has now been integrated. Changeset: 16d917a8 Author: Taizo Kurashige <103394724+kurashige23 at users.noreply.github.com> Committer: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/16d917a85f9311611a14a63f1e53afae970efc73 Stats: 113 lines in 2 files changed: 0 ins; 0 del; 113 mod 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump Reviewed-by: dholmes, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/16413 From ihse at openjdk.org Tue Feb 27 11:19:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:19:59 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 08:14:56 GMT, Julian Waters wrote: > can we get rid of LDCXX? Yeah, that is something I plan to look into. Linking C++ object files with gcc will fail; and it might be that linking pure C with g++ might be problematic. If this is the case, I hope we can at least determine this automatically which linker frontend to use, i.e. selecting g++ as linker frontend if there is at least one .cpp file in the set of sources. This PR is actually a kind of prerequisite for that kind of work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966312751 From ihse at openjdk.org Tue Feb 27 11:19:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:19:59 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: <84uF4N9DtS5RqXpGr2X8x-QZkztakWV8XYlq1aGP6Ac=.0d0ea683-75c0-4e97-97bf-e30eefe1e170@github.com> On Tue, 27 Feb 2024 08:29:44 GMT, Julian Waters wrote: > All those new parameters to SetupNativeCompilation, were they always there and the comments about them were just missing from the documentation about the function? Yep. The toolchain definition was a way to "package" multiple arguments to SetupNativeCompilation, so you did not have to specify them individually in each call. But in the end they just turned into "normal" arguments to SetupNativeCompilation (but undocumented...). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966314926 From ihse at openjdk.org Tue Feb 27 11:19:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:19:59 GMT Subject: Integrated: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. This pull request has now been integrated. Changeset: ac3ce2aa Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/ac3ce2aa156332fc4e6f33018ff669657ab4b797 Stats: 231 lines in 14 files changed: 58 ins; 142 del; 31 mod 8326583: Remove over-generalized DefineNativeToolchain solution Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/17986 From ihse at openjdk.org Tue Feb 27 11:19:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:19:59 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4] In-Reply-To: References: Message-ID: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into remove-toolchain-define - Rename LANG to LINK_TYPE - Reword "lib" comment to fit in better - Merge branch 'master' into remove-toolchain-define - 8326583: Remove over-generalized DefineNativeToolchain solution ------------- Changes: https://git.openjdk.org/jdk/pull/17986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=03 Stats: 231 lines in 14 files changed: 58 ins; 142 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/17986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986 PR: https://git.openjdk.org/jdk/pull/17986 From jwaters at openjdk.org Tue Feb 27 11:29:47 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 11:29:47 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:09:26 GMT, Magnus Ihse Bursie wrote: > > can we get rid of LDCXX? > > Yeah, that is something I plan to look into. Linking C++ object files with gcc will fail; and it might be that linking pure C with g++ might be problematic. If this is the case, I hope we can at least determine this automatically which linker frontend to use, i.e. selecting g++ as linker frontend if there is at least one .cpp file in the set of sources. > > This PR is actually a kind of prerequisite for that kind of work. I'd certainly opt for selecting which linker driver to use automatically than using one for both; According to some discussions with several gcc maintainers (https://web.libera.chat/) they really aren't meant to be intermingled Also was fine with LANG; There wasn't a need to change it to LINK_TYPE, but oh well ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966341897 From djelinski at openjdk.org Tue Feb 27 11:46:48 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 27 Feb 2024 11:46:48 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into remove-toolchain-define > - Rename LANG to LINK_TYPE > - Reword "lib" comment to fit in better > - Merge branch 'master' into remove-toolchain-define > - 8326583: Remove over-generalized DefineNativeToolchain solution FWIW, when I added `-lstdc++` before both `-static-libstdc++` and replaced LDCXX with LD, the code compiled and linked just fine. Both GCC and G++ call the same linker, and the parameter differences are well documented. It's only a matter of deciding if we want to keep the complexity of selecting the executable to use or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966368056 From ihse at openjdk.org Tue Feb 27 12:01:53 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 12:01:53 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:44:31 GMT, Daniel Jeli?ski wrote: > FWIW, when I added -lstdc++ before both -static-libstdc++ and replaced LDCXX with LD, the code compiled and linked just fine. Both GCC and G++ call the same linker, and the parameter differences are well documented. It's only a matter of deciding if we want to keep the complexity of selecting the executable to use or not. My thinking matches yours. It would be nice to get rid of LDCXX. I'll look into it as a follow-up project. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966390350 From jwaters at openjdk.org Tue Feb 27 12:50:48 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 12:50:48 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into remove-toolchain-define > - Rename LANG to LINK_TYPE > - Reword "lib" comment to fit in better > - Merge branch 'master' into remove-toolchain-define > - 8326583: Remove over-generalized DefineNativeToolchain solution I can't really say I agree, but I guess we'll see where this goes from here first ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966471047 From lmesnik at openjdk.org Tue Feb 27 19:00:56 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Feb 2024 19:00:56 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v17] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 18:40:10 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix a typo in libObjectMonitorUsage.cpp There is one comment about changing #define for thread.hpp. The test changes look good for me. Thanks for converting the test from vmTetbase. src/hotspot/share/runtime/threads.cpp line 1185: > 1183: } > 1184: > 1185: #if INCLUDE_JVMTI Is it needed to update thread.hpp also? ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1904467409 PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1504740367 From sspitsyn at openjdk.org Tue Feb 27 19:11:57 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Feb 2024 19:11:57 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v17] In-Reply-To: References: Message-ID: <2ZAm5hDpXOpLEGvHIjd2MeM1CXuAf9Kh2wLeMkdHPms=.5ddc053e-54b9-4b7d-9a8a-5f2798617f21@github.com> On Fri, 23 Feb 2024 18:40:10 GMT, Serguei Spitsyn wrote: >> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec. >> The function returns the following structure: >> >> >> typedef struct { >> jthread owner; >> jint entry_count; >> jint waiter_count; >> jthread* waiters; >> jint notify_waiter_count; >> jthread* notify_waiters; >> } jvmtiMonitorUsage; >> >> >> The following four fields are defined this way: >> >> waiter_count [jint] The number of threads waiting to own this monitor >> waiters [jthread*] The waiter_count waiting threads >> notify_waiter_count [jint] The number of threads waiting to be notified by this monitor >> notify_waiters [jthread*] The notify_waiter_count threads waiting to be notified >> >> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`. >> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong. >> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`. >> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong. >> This update makes it right. >> >> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command. >> >> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior: >> >> jvmti/GetObjectMonitorUsage/objmonusage001 >> jvmti/GetObjectMonitorUsage/objmonusage003 >> >> >> The following JVMTI JCK tests have to be fixed to adopt to correct behavior: >> >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html >> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html >> >> >> >> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository. >> >> Also, please see and review the related CSR: >> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage >> >> The Release-Note is: >> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage >> >> Testing: >> - tested with mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix a typo in libObjectMonitorUsage.cpp Thank you for review, Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1967416721 From sspitsyn at openjdk.org Tue Feb 27 19:11:57 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Feb 2024 19:11:57 GMT Subject: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v17] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 18:24:04 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix a typo in libObjectMonitorUsage.cpp > > src/hotspot/share/runtime/threads.cpp line 1185: > >> 1183: } >> 1184: >> 1185: #if INCLUDE_JVMTI > > Is it needed to update thread.hpp also? Thank you for the comment, will check it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1504802182 From cjplummer at openjdk.org Tue Feb 27 19:26:59 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Feb 2024 19:26:59 GMT Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves created files in the /tmp dir. Message-ID: PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to write the perfmap to. It does this in 3 different modes. 2 of the modes result in a perfmap file being left in the tmp directory that is not removed after the test executes (and should be removed). The 3rd mode creates the perfmap file in the directory specified by the test.dir property, and is ok to leave the file there. I've added code to delete the /tmp files that are created. I did a bit of extra testing by hand. I created /tmp/perf-.map as root. As expected the Files.deleteIfExists() call threw an exception due to the lack of permissions to delete the file. However, I then realized the file had a size of 0, which means the test was not even doing a proper job of testing that the perfrmap jcmd was working. In other words, the test should have failed long before getting to the Files.deleteIfExists(), so I added a size check to make sure it fails when the file is not written to. ------------- Commit messages: - Delete tmp files Changes: https://git.openjdk.org/jdk/pull/17992/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17992&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325532 Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17992/head:pull/17992 PR: https://git.openjdk.org/jdk/pull/17992 From kbarrett at openjdk.org Wed Feb 28 01:24:41 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 28 Feb 2024 01:24:41 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers Message-ID: Please review this change that renames some test .h files to .hpp. These files contain C++ code and should be named accordingly. Some of them contain uses of NULL, which we change to nullptr. The renamed files are: test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h test/lib/jdk/test/lib/jvmti/jvmti_thread.h test/lib/jdk/test/lib/jvmti/jvmti_common.h test/lib/native/testlib_threads.h The #include updates were performed mostly mechanically, and builds would fail if there were mistakes. The exception is test test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, which was added after I'd done the mechanical update, so was updated by hand. The copyright updates were similarly performed mechanically. All but a handful of the including files have already had their copyrights updated recently, likely as part of JDK-8324681. Thus, the only "interesting" changes are to the renamed files. Testing: mach5 tier1 ------------- Commit messages: - update new test - update copyrights - fix jvmti README - rename NULLs in jvmti_common.hpp - rename jvmti_common.h - rename NULLs in jvmti_thread.hpp - rename jvmti_thread.h - rename NULLs in testlib_threads.hpp - rename testlib_threads.h -- no copyright - rename nsk_tools.h -- no copyright - ... and 5 more: https://git.openjdk.org/jdk/compare/16d917a8...4154005e Changes: https://git.openjdk.org/jdk/pull/18035/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18035&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324799 Stats: 1535 lines in 731 files changed: 133 ins; 133 del; 1269 mod Patch: https://git.openjdk.org/jdk/pull/18035.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18035/head:pull/18035 PR: https://git.openjdk.org/jdk/pull/18035 From amenkov at openjdk.org Wed Feb 28 01:58:51 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 28 Feb 2024 01:58:51 GMT Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves created files in the /tmp dir. In-Reply-To: References: