From bchristi at openjdk.java.net Wed Dec 1 18:21:04 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 1 Dec 2021 18:21:04 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v2] In-Reply-To: References: Message-ID: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge branch 'master' into 8276447 - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - Indicate that runFinalizers does nothing if finalization is disabled or removed - Fix @since on @Deprecated for java.lang.Enum - ... and 22 more: https://git.openjdk.java.net/jdk/compare/a363b7b9...e4986a48 ------------- Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=01 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From bchristi at openjdk.java.net Wed Dec 1 19:23:59 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 1 Dec 2021 19:23:59 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v3] In-Reply-To: References: Message-ID: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Merge branch 'master' into 8276447 - Merge branch 'master' into 8276447 - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - Indicate that runFinalizers does nothing if finalization is disabled or removed - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674 ------------- Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=02 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From serguei.spitsyn at oracle.com Wed Dec 1 21:57:48 2021 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Wed, 1 Dec 2021 21:57:48 +0000 Subject: JVMTI Class load callback not being called on Windows, but works on Linux In-Reply-To: <7d107085-b6cb-e36e-c977-5422884a2240@oracle.com> References: <6b650f6d-4f7e-d75a-2cc1-ea96336256e5@gmail.com> <01C7DD0F-B495-465A-BF06-31CC28217FF6@oracle.com> <7d107085-b6cb-e36e-c977-5422884a2240@oracle.com> Message-ID: Hi Charlie, I do not see any obvious errors in your code except what Mikael mentioned below. Could you, please, check if asserts are really enabled in your runs on Windows? Also, I agree with Mikael that it would be better to get rid of these asserts or refactor the code to use asserts only to check results like below: jvmtiError err = jvmti->AddCapabilities(&capabilities); assert(res == JVMTI_ERROR_NONE); Also, what are your command-line options? Thanks, Serguei ?On 12/1/21, 1:17 AM, "hotspot-dev on behalf of Daniel D. Daugherty" wrote: Redirecting to the serviceability-dev at ... alias since JVM/TI is maintained by the Serviceability team... Dan On 1/10/21 6:09 PM, Mikael Vidstedt wrote: > Just a control question: Are you *sure* asserts are actually enabled? Having actual application logic in an assert is normally a bad idea because if/when you compile the release/production version with asserts disabled the application behavior will change. > > Cheers, > Mikael > >> On Jan 10, 2021, at 8:33 AM, Charlie wrote: >> >> Hi, >> >> I have a working jvmti agent on Linux (Java(TM) SE Runtime Environment (build 1.8.0_271-b09)) that hooks the class load event. >> >> This same agent compiled for windows claims to work (all asserts pass), but my hook never gets called, is anyone able to tell me why? >> >> I register my callback like so: >> >> jint res = vm->GetEnv(reinterpret_cast(&jvmti), JVMTI_VERSION_1); >> if (res != JNI_OK || jvmti==nullptr) { >> fprintf(stderr,"Unable to get JVMTI!"); >> } >> assert(res == JVMTI_ERROR_NONE); >> >> jvmtiCapabilities capabilities = {0}; >> capabilities.can_retransform_classes=1; >> capabilities.can_generate_all_class_hook_events = 1; >> >> assert(jvmti->AddCapabilities(&capabilities) == JVMTI_ERROR_NONE); >> >> jvmtiEventCallbacks callbacks; >> memset(&callbacks,0,sizeof(callbacks)); >> callbacks.ClassFileLoadHook = &class_file_load_hook_handler; >> assert(jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks)) == JVMTI_ERROR_NONE); >> assert(jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_CLASS_FILE_LOAD_HOOK, nullptr) == JVMTI_ERROR_NONE); >> >> The callback itself is as follows: >> >> static void JNICALL class_file_load_hook_handler( >> jvmtiEnv* jvmti, >> JNIEnv* env, >> jclass class_being_redefined, >> jobject loader, >> const char* name, >> jobject protection_domain, >> jint class_data_len, >> const unsigned char* class_data, >> jint* new_class_data_len, >> unsigned char** new_class_data >> ) { >> if (name == nullptr) { >> return; >> } >> >> printf("loaded %s\n",name); >> >> } >> >> (to clarify, all JNI functions in the lib work fine) >> >> The Windows machine's java version string is this: >> >> java version "1.8.0_271" >> Java(TM) SE Runtime Environment (build 1.8.0_271-b09) >> Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode) >> From smarks at openjdk.java.net Thu Dec 2 01:26:30 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 2 Dec 2021 01:26:30 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v3] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian wrote: >> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. >> >> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. >> >> The CSR has been approved. >> An automated test build+test run passes cleanly (FWIW :D ). > > Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into 8276447 > - Merge branch 'master' into 8276447 > - merge > - @SuppressWarnings(removal) in Windows CKey.java > - Add jls tag to runFinalization methods > - Update wording of Object.finalize, new paragraph is now bold > - update Object.finalize javadoc > - update Object.finalize JavaDoc and @deprecated tag > - Update Object.finalize deprecation message > - Indicate that runFinalizers does nothing if finalization is disabled or removed > - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674 Marked as reviewed by smarks (Reviewer). src/jdk.jconsole/share/classes/sun/tools/jconsole/SummaryTab.java line 116: > 114: StringBuilder buf; > 115: > 116: @SuppressWarnings("deprecation") Item for future cleanup: refactor the call to `getObjectPendingFinalizationCount()` at line 219 (!) into a local variable declaration, and then move the warnings suppression to that declaration. This reduces the scope of warnings suppression. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From shade at openjdk.java.net Thu Dec 2 09:35:29 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Dec 2021 09:35:29 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v5] In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 11:26:04 GMT, Andrew Haley wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - Fix a comment >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - More reviews >> - Review feedback >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - Initial work: runs async-profiler successfully > > src/hotspot/cpu/zero/frame_zero.cpp line 139: > >> 137: assert(is_interpreted_frame(), "Not an interpreted frame"); >> 138: // These are reasonable sanity checks >> 139: if (fp() == 0 || (intptr_t(fp()) & (wordSize-1)) != 0) { > > Use `is_aligned()` here? @theRealAph Do you agree with above? Any more comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From cjplummer at openjdk.java.net Thu Dec 2 17:45:51 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 2 Dec 2021 17:45:51 GMT Subject: RFR: 8258512: serviceability/sa/TestJmapCore.java timed out on macOS 10.13.6 Message-ID: Increase the test timeout to 480 just to make sure we don't see this timeout anymore. This same change was already made to TestJmapCoreMetaspace.java a long time ago. ------------- Commit messages: - Increase test timeout from 240 to 480 Changes: https://git.openjdk.java.net/jdk/pull/6676/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6676&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258512 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6676.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6676/head:pull/6676 PR: https://git.openjdk.java.net/jdk/pull/6676 From lmesnik at openjdk.java.net Thu Dec 2 19:32:16 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 2 Dec 2021 19:32:16 GMT Subject: RFR: 8258512: serviceability/sa/TestJmapCore.java timed out on macOS 10.13.6 In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 17:36:43 GMT, Chris Plummer wrote: > Increase the test timeout to 480 just to make sure we don't see this timeout anymore. This same change was already made to TestJmapCoreMetaspace.java a long time ago. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6676 From dcubed at openjdk.java.net Thu Dec 2 19:52:18 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 2 Dec 2021 19:52:18 GMT Subject: RFR: 8258512: serviceability/sa/TestJmapCore.java timed out on macOS 10.13.6 In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 17:36:43 GMT, Chris Plummer wrote: > Increase the test timeout to 480 just to make sure we don't see this timeout anymore. This same change was already made to TestJmapCoreMetaspace.java a long time ago. Thumbs up. This is a trivial change. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6676 From duke at openjdk.java.net Thu Dec 2 21:02:40 2021 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 2 Dec 2021 21:02:40 GMT Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java Message-ID: JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java ------------- Commit messages: - Merge branch 'master' into JDK-8276681 - Fix missing '@' in javadoc for JDK-8276681 Changes: https://git.openjdk.java.net/jdk/pull/6486/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6486&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276681 Stats: 13 lines in 10 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/6486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6486/head:pull/6486 PR: https://git.openjdk.java.net/jdk/pull/6486 From lancea at openjdk.java.net Thu Dec 2 21:08:17 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 2 Dec 2021 21:08:17 GMT Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java In-Reply-To: References: Message-ID: On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing wrote: > JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6486 From duke at openjdk.java.net Thu Dec 2 21:25:53 2021 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 2 Dec 2021 21:25:53 GMT Subject: RFR: JDK-8276681: Additional malformed Javadoc inline tags in JDK source [v2] In-Reply-To: References: Message-ID: > JDK-8276681: Additional malformed Javadoc inline tags in JDK source Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8276681 - Merge branch 'master' into JDK-8276681 - Fix missing '@' in javadoc for JDK-8276681 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6486/files - new: https://git.openjdk.java.net/jdk/pull/6486/files/e8071197..8eaf05bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6486&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6486&range=00-01 Stats: 29529 lines in 653 files changed: 17761 ins; 7341 del; 4427 mod Patch: https://git.openjdk.java.net/jdk/pull/6486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6486/head:pull/6486 PR: https://git.openjdk.java.net/jdk/pull/6486 From duke at openjdk.java.net Thu Dec 2 21:25:54 2021 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 2 Dec 2021 21:25:54 GMT Subject: Integrated: JDK-8276681: Additional malformed Javadoc inline tags in JDK source In-Reply-To: References: Message-ID: On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing wrote: > JDK-8276681: Additional malformed Javadoc inline tags in JDK source This pull request has now been integrated. Changeset: b8ac0d20 Author: Tim Prinzing Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/b8ac0d20ceec26b3a1dd0b9577817fa6320ea9ef Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod 8276681: Additional malformed Javadoc inline tags in JDK source Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/6486 From cjplummer at openjdk.java.net Thu Dec 2 22:20:15 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 2 Dec 2021 22:20:15 GMT Subject: RFR: 8258512: serviceability/sa/TestJmapCore.java timed out on macOS 10.13.6 In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 17:36:43 GMT, Chris Plummer wrote: > Increase the test timeout to 480 just to make sure we don't see this timeout anymore. This same change was already made to TestJmapCoreMetaspace.java a long time ago. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/6676 From cjplummer at openjdk.java.net Thu Dec 2 22:20:16 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 2 Dec 2021 22:20:16 GMT Subject: Integrated: 8258512: serviceability/sa/TestJmapCore.java timed out on macOS 10.13.6 In-Reply-To: References: Message-ID: <0p7EfUJuy527SaOxAcBv4KELZ-z1qmulIXapq4KUbO8=.c5c9edce-50e6-4a77-8598-8f4aac6d1b69@github.com> On Thu, 2 Dec 2021 17:36:43 GMT, Chris Plummer wrote: > Increase the test timeout to 480 just to make sure we don't see this timeout anymore. This same change was already made to TestJmapCoreMetaspace.java a long time ago. This pull request has now been integrated. Changeset: 19ce33d5 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/19ce33d5e770dc3fd7a9588e7954bbb499b7a05c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8258512: serviceability/sa/TestJmapCore.java timed out on macOS 10.13.6 Reviewed-by: lmesnik, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/6676 From cjplummer at openjdk.java.net Fri Dec 3 05:25:31 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 3 Dec 2021 05:25:31 GMT Subject: RFR: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' Message-ID: The issue appears to be due to running jstack before allowing the 4 threads created by `LingeredAppWithLock` to fully start up and reach their blocking or timed wait state. With this fix `LingeredAppWithLock.main()` now waits until the threads have reached the blocking or timed wait state before calling into `LingeredApp.main()`. Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which will first launch `LingeredAppWithLock` and then block until the lock file is touched. This blocking/waiting is done the call to `waitAppReady()`, which will be called before `LingeredApp.startApp()` returns. The lock file is not touched until `LingeredApp.main()` is called, and it is not called until after `LingeredAppWithBloc.main()` has already verified the state of all the threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure that the threads started by `LingeredAppWithLock.main()` are in the desired state. ------------- Commit messages: - Don't run jstack until after all target process threads are done starting up. Changes: https://git.openjdk.java.net/jdk/pull/6689/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6689&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8210558 Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6689.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6689/head:pull/6689 PR: https://git.openjdk.java.net/jdk/pull/6689 From cjplummer at openjdk.java.net Fri Dec 3 07:08:17 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 3 Dec 2021 07:08:17 GMT Subject: RFR: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 05:17:26 GMT, Chris Plummer wrote: > The issue appears to be due to running jstack before allowing the 4 threads created by `LingeredAppWithLock` to fully start up and reach their blocking or timed wait state. With this fix `LingeredAppWithLock.main()` now waits until the threads have reached the blocking or timed wait state before calling into `LingeredApp.main()`. > > Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which will first launch `LingeredAppWithLock` and then block until the lock file is touched. This blocking/waiting is done the call to `waitAppReady()`, which will be called before `LingeredApp.startApp()` returns. The lock file is not touched until `LingeredApp.main()` is called, and it is not called until after `LingeredAppWithBloc.main()` has already verified the state of all the threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure that the threads started by `LingeredAppWithLock.main()` are in the desired state. I got some test failures when doing a large number of test runs. Need to investigate. Withdrawing for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/6689 From cjplummer at openjdk.java.net Fri Dec 3 07:08:17 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 3 Dec 2021 07:08:17 GMT Subject: Withdrawn: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 05:17:26 GMT, Chris Plummer wrote: > The issue appears to be due to running jstack before allowing the 4 threads created by `LingeredAppWithLock` to fully start up and reach their blocking or timed wait state. With this fix `LingeredAppWithLock.main()` now waits until the threads have reached the blocking or timed wait state before calling into `LingeredApp.main()`. > > Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which will first launch `LingeredAppWithLock` and then block until the lock file is touched. This blocking/waiting is done the call to `waitAppReady()`, which will be called before `LingeredApp.startApp()` returns. The lock file is not touched until `LingeredApp.main()` is called, and it is not called until after `LingeredAppWithBloc.main()` has already verified the state of all the threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure that the threads started by `LingeredAppWithLock.main()` are in the desired state. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6689 From cjplummer at openjdk.java.net Sat Dec 4 04:09:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sat, 4 Dec 2021 04:09:13 GMT Subject: RFR: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 05:17:26 GMT, Chris Plummer wrote: > The issue appears to be due to running jstack before allowing the 4 threads created by `LingeredAppWithLock` to fully start up and reach their blocking or timed wait state. With this fix `LingeredAppWithLock.main()` now waits until the threads have reached the blocking or timed wait state before calling into `LingeredApp.main()`. > > Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which will first launch `LingeredAppWithLock` and then block until the lock file is touched. This blocking/waiting is done the call to `waitAppReady()`, which will be called before `LingeredApp.startApp()` returns. The lock file is not touched until `LingeredApp.main()` is called, and it is not called until after `LingeredAppWithBloc.main()` has already verified the state of all the threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure that the threads started by `LingeredAppWithLock.main()` are in the desired state. These test failures I am occasionally seeing also occur without my changes and appear to be due to OSX host issues, so I'm reopening this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6689 From coleenp at openjdk.java.net Sat Dec 4 13:08:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sat, 4 Dec 2021 13:08:18 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 07:18:22 GMT, Thomas Stuefe wrote: > This bypasses the currently observed problem, but we still have a fundamentally unsafe mechanism in use here. :( Definitely. I think having some assert code that verifies that we don't do anything "unsafe" while in AsyncGetCallTrace might be a good enhancement, but the definition of "unsafe" in this case might be almost anything we do. This change chops off a piece of the top of the iceberg as observed. Thanks for all the code reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/6606 From coleenp at openjdk.java.net Sat Dec 4 13:08:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sat, 4 Dec 2021 13:08:19 GMT Subject: Integrated: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore wrote: > This change seems to keep the test case in the bug from crashing in the ResourceMark destructor. We have a ResourceMark during stack walking in AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix care of @fisk. > Testing tier1-6 in progress. This pull request has now been integrated. Changeset: 267c024e Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/267c024eb52acd1611188dd5b1417b877ff3eafd Stats: 9 lines in 2 files changed: 0 ins; 3 del; 6 mod 8265150: AsyncGetCallTrace crashes on ResourceMark Reviewed-by: dholmes, stuefe, eosterlund, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6606 From darcy at openjdk.java.net Sun Dec 5 23:53:39 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 5 Dec 2021 23:53:39 GMT Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks Message-ID: Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them. (Enabling the reference checks is left for future work.) ------------- Commit messages: - JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks Changes: https://git.openjdk.java.net/jdk/pull/6713/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6713&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278273 Stats: 14 lines in 7 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6713/head:pull/6713 PR: https://git.openjdk.java.net/jdk/pull/6713 From iris at openjdk.java.net Mon Dec 6 06:19:14 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 6 Dec 2021 06:19:14 GMT Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks In-Reply-To: References: Message-ID: <53hKkuTiEAI3u8ktsivvFxPwR0ZS-B8rgpLDmApjyIs=.00cd21e6-1731-4507-955a-a125b416aa13@github.com> On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy wrote: > Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them. > > (Enabling the reference checks is left for future work.) Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6713 From alanb at openjdk.java.net Mon Dec 6 07:08:12 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 6 Dec 2021 07:08:12 GMT Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks In-Reply-To: References: Message-ID: <9SgzaJHojLAPSAitHsNAMOfU1ghzZWmKXT6OJEUsteQ=.c09933d0-7ce6-4bcd-8a58-d3a87d44ca88@github.com> On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy wrote: > Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them. > > (Enabling the reference checks is left for future work.) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6713 From kevinw at openjdk.java.net Mon Dec 6 10:27:19 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 6 Dec 2021 10:27:19 GMT Subject: RFR: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 05:17:26 GMT, Chris Plummer wrote: > The issue appears to be due to running jstack before allowing the 4 threads created by `LingeredAppWithLock` to fully start up and reach their blocking or timed wait state. With this fix `LingeredAppWithLock.main()` now waits until the threads have reached the blocking or timed wait state before calling into `LingeredApp.main()`. > > Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which will first launch `LingeredAppWithLock` and then block until the lock file is touched. This blocking/waiting is done the call to `waitAppReady()`, which will be called before `LingeredApp.startApp()` returns. The lock file is not touched until `LingeredApp.main()` is called, and it is not called until after `LingeredAppWithBloc.main()` has already verified the state of all the threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure that the threads started by `LingeredAppWithLock.main()` are in the desired state. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6689 From sspitsyn at openjdk.java.net Mon Dec 6 11:08:15 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 6 Dec 2021 11:08:15 GMT Subject: RFR: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 05:17:26 GMT, Chris Plummer wrote: > The issue appears to be due to running jstack before allowing the 4 threads created by `LingeredAppWithLock` to fully start up and reach their blocking or timed wait state. With this fix `LingeredAppWithLock.main()` now waits until the threads have reached the blocking or timed wait state before calling into `LingeredApp.main()`. > > Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which will first launch `LingeredAppWithLock` and then block until the lock file is touched. This blocking/waiting is done the call to `waitAppReady()`, which will be called before `LingeredApp.startApp()` returns. The lock file is not touched until `LingeredApp.main()` is called, and it is not called until after `LingeredAppWithBloc.main()` has already verified the state of all the threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure that the threads started by `LingeredAppWithLock.main()` are in the desired state. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6689 From ihse at openjdk.java.net Mon Dec 6 11:52:13 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 6 Dec 2021 11:52:13 GMT Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks In-Reply-To: References: Message-ID: On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy wrote: > Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them. > > (Enabling the reference checks is left for future work.) ?? ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6713 From cjplummer at openjdk.java.net Mon Dec 6 16:13:21 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 6 Dec 2021 16:13:21 GMT Subject: RFR: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 05:17:26 GMT, Chris Plummer wrote: > The issue appears to be due to running jstack before allowing the 4 threads created by `LingeredAppWithLock` to fully start up and reach their blocking or timed wait state. With this fix `LingeredAppWithLock.main()` now waits until the threads have reached the blocking or timed wait state before calling into `LingeredApp.main()`. > > Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which will first launch `LingeredAppWithLock` and then block until the lock file is touched. This blocking/waiting is done the call to `waitAppReady()`, which will be called before `LingeredApp.startApp()` returns. The lock file is not touched until `LingeredApp.main()` is called, and it is not called until after `LingeredAppWithBloc.main()` has already verified the state of all the threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure that the threads started by `LingeredAppWithLock.main()` are in the desired state. Thanks for the reviews Serguei and Kevin! ------------- PR: https://git.openjdk.java.net/jdk/pull/6689 From cjplummer at openjdk.java.net Mon Dec 6 16:13:22 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 6 Dec 2021 16:13:22 GMT Subject: Integrated: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 05:17:26 GMT, Chris Plummer wrote: > The issue appears to be due to running jstack before allowing the 4 threads created by `LingeredAppWithLock` to fully start up and reach their blocking or timed wait state. With this fix `LingeredAppWithLock.main()` now waits until the threads have reached the blocking or timed wait state before calling into `LingeredApp.main()`. > > Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which will first launch `LingeredAppWithLock` and then block until the lock file is touched. This blocking/waiting is done the call to `waitAppReady()`, which will be called before `LingeredApp.startApp()` returns. The lock file is not touched until `LingeredApp.main()` is called, and it is not called until after `LingeredAppWithBloc.main()` has already verified the state of all the threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure that the threads started by `LingeredAppWithLock.main()` are in the desired state. This pull request has now been integrated. Changeset: 587e5409 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/587e5409c2488cf8c3579a4932c588efc5a02749 Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' Reviewed-by: kevinw, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6689 From darcy at openjdk.java.net Mon Dec 6 17:00:19 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 6 Dec 2021 17:00:19 GMT Subject: Integrated: JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks In-Reply-To: References: Message-ID: On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy wrote: > Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them. > > (Enabling the reference checks is left for future work.) This pull request has now been integrated. Changeset: 5045eb53 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/5045eb538b3afc6cf646642f1109473597b3004a Stats: 14 lines in 7 files changed: 0 ins; 0 del; 14 mod 8278273: Remove unnecessary exclusion of doclint accessibility checks Reviewed-by: iris, alanb, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/6713 From prr at openjdk.java.net Mon Dec 6 17:57:14 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 6 Dec 2021 17:57:14 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v3] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian wrote: >> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. >> >> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. >> >> The CSR has been approved. >> An automated test build+test run passes cleanly (FWIW :D ). > > Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into 8276447 > - Merge branch 'master' into 8276447 > - merge > - @SuppressWarnings(removal) in Windows CKey.java > - Add jls tag to runFinalization methods > - Update wording of Object.finalize, new paragraph is now bold > - update Object.finalize javadoc > - update Object.finalize JavaDoc and @deprecated tag > - Update Object.finalize deprecation message > - Indicate that runFinalizers does nothing if finalization is disabled or removed > - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From bchristi at openjdk.java.net Mon Dec 6 20:41:43 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 6 Dec 2021 20:41:43 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v4] In-Reply-To: References: Message-ID: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'master' into 8276447 - Merge branch 'master' into 8276447 - Merge branch 'master' into 8276447 - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - ... and 24 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...0a983d51 ------------- Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=03 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From sspitsyn at openjdk.java.net Tue Dec 7 00:35:27 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 7 Dec 2021 00:35:27 GMT Subject: RFR: 8272395: Bad HTML in JVMTI man page Message-ID: This fix adds escaping of invalid characters '[]' for 3 URLs defined in the jvmti.xml. This file is a base to generate the jvmti.html. ------------- Commit messages: - fix: 8272395: Bad HTML in JVMTI man page Changes: https://git.openjdk.java.net/jdk/pull/6730/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6730&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272395 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6730.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6730/head:pull/6730 PR: https://git.openjdk.java.net/jdk/pull/6730 From dholmes at openjdk.java.net Tue Dec 7 01:57:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 7 Dec 2021 01:57:12 GMT Subject: RFR: 8272395: Bad HTML in JVMTI man page In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 00:27:45 GMT, Serguei Spitsyn wrote: > This fix adds escaping of invalid characters '[]' for 3 URLs defined in the jvmti.xml. > This file is a base to generate the jvmti.html. Looks good and trivial. I never realized the browser was presenting a user-friendly version of the URL, showing the [], but if you copy and past the URL they are converted to %5B%5D. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6730 From iris at openjdk.java.net Tue Dec 7 03:41:17 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 7 Dec 2021 03:41:17 GMT Subject: RFR: 8272395: Bad HTML in JVMTI man page In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 00:27:45 GMT, Serguei Spitsyn wrote: > This fix adds escaping of invalid characters '[]' for 3 URLs defined in the jvmti.xml. > This file is a base to generate the jvmti.html. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6730 From sspitsyn at openjdk.java.net Tue Dec 7 08:20:17 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 7 Dec 2021 08:20:17 GMT Subject: RFR: 8272395: Bad HTML in JVMTI man page In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 00:27:45 GMT, Serguei Spitsyn wrote: > This fix adds escaping of invalid characters '[]' for 3 URLs defined in the jvmti.xml. > This file is a base to generate the jvmti.html. Thank you for review, David and Iris! ------------- PR: https://git.openjdk.java.net/jdk/pull/6730 From sspitsyn at openjdk.java.net Tue Dec 7 08:20:17 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 7 Dec 2021 08:20:17 GMT Subject: Integrated: 8272395: Bad HTML in JVMTI man page In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 00:27:45 GMT, Serguei Spitsyn wrote: > This fix adds escaping of invalid characters '[]' for 3 URLs defined in the jvmti.xml. > This file is a base to generate the jvmti.html. This pull request has now been integrated. Changeset: e535cb3f Author: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/e535cb3fbac11785cfdb43c9b6f73b2a38a621d6 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8272395: Bad HTML in JVMTI man page Reviewed-by: dholmes, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/6730 From sspitsyn at openjdk.java.net Tue Dec 7 09:20:30 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 7 Dec 2021 09:20:30 GMT Subject: RFR: 8278330: dump stack trace if the jvmti test nsk/jvmti/GetThreadState/thrstat002 is failed with wrong thread state Message-ID: This is a fix for sub-task of: 8271065: vmTestbase/nsk/jvmti/GetThreadState/thrstat002 still fails with "Wrong thread "thr1" (...) state after SuspendThread" The vmTestbase/nsk/jvmti/GetThreadState/thrstat002 test is intermittently failing with the wrong thread state reported. It is most likely because of the unexpected JFR (or NMT) activity. In order to confirm this guess we need to dump the stack trace in a case of this failure. ------------- Commit messages: - fixed: 8278330 dump stack trace if the jvmti test nsk/jvmti/GetThreadState/thrstat002 is failed with wrong thread state Changes: https://git.openjdk.java.net/jdk/pull/6735/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6735&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278330 Stats: 101 lines in 1 file changed: 101 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6735.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6735/head:pull/6735 PR: https://git.openjdk.java.net/jdk/pull/6735 From gdub at openjdk.java.net Tue Dec 7 11:16:17 2021 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Tue, 7 Dec 2021 11:16:17 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes [v2] In-Reply-To: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> References: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> Message-ID: On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe wrote: >> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: >> >> >> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, >> jstring command, dcmdArgInfo* infoArray) >> >> >> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. >> >> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. >> >> ------------- >> >> Testing: >> - manual tests with artificially induced error in one dcmd for debug, release >> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Remove changes to GetDiagnosticCommandInfo Just out of curiosity, for such changes, should we in principle bump `JMM_VERSION`? Or do we not care because libjvm and libmanagement are always shipped together? ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From shade at openjdk.java.net Tue Dec 7 11:32:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 7 Dec 2021 11:32:16 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v5] In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 11:26:04 GMT, Andrew Haley wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - Fix a comment >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - More reviews >> - Review feedback >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - Initial work: runs async-profiler successfully > > src/hotspot/cpu/zero/frame_zero.cpp line 139: > >> 137: assert(is_interpreted_frame(), "Not an interpreted frame"); >> 138: // These are reasonable sanity checks >> 139: if (fp() == 0 || (intptr_t(fp()) & (wordSize-1)) != 0) { > > Use `is_aligned()` here? Paging @theRealAph ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From stuefe at openjdk.java.net Tue Dec 7 13:11:13 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 7 Dec 2021 13:11:13 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes [v2] In-Reply-To: References: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> Message-ID: On Tue, 7 Dec 2021 11:13:01 GMT, Gilles Duboscq wrote: > Just out of curiosity, for such changes, should we in principle bump `JMM_VERSION`? Or do we not care because libjvm and libmanagement are always shipped together? Hmm, maybe you are right, though someone from Oracle may answer that better. However, seeing that JMM is an internal interface between two internal components, I am not even sure why this version check is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From bpb at openjdk.java.net Thu Dec 9 22:06:00 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 9 Dec 2021 22:06:00 GMT Subject: [jdk18] Integrated: 8278521: ProblemList java/lang/management/ThreadMXBean/ThreadLists.java In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 21:57:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/management/ThreadMXBean/ThreadLists.java on all configs. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/3 From dcubed at openjdk.java.net Thu Dec 9 22:06:00 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 9 Dec 2021 22:06:00 GMT Subject: [jdk18] Integrated: 8278521: ProblemList java/lang/management/ThreadMXBean/ThreadLists.java Message-ID: A trivial fix to ProblemList java/lang/management/ThreadMXBean/ThreadLists.java on all configs. ------------- Commit messages: - 8278521: ProblemList java/lang/management/ThreadMXBean/ThreadLists.java Changes: https://git.openjdk.java.net/jdk18/pull/3/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=3&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278521 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk18/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/3/head:pull/3 PR: https://git.openjdk.java.net/jdk18/pull/3 From dcubed at openjdk.java.net Thu Dec 9 22:06:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 9 Dec 2021 22:06:01 GMT Subject: [jdk18] Integrated: 8278521: ProblemList java/lang/management/ThreadMXBean/ThreadLists.java In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 21:59:19 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList java/lang/management/ThreadMXBean/ThreadLists.java on all configs. > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.java.net/jdk18/pull/3 From dcubed at openjdk.java.net Thu Dec 9 22:06:02 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 9 Dec 2021 22:06:02 GMT Subject: [jdk18] Integrated: 8278521: ProblemList java/lang/management/ThreadMXBean/ThreadLists.java In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 21:57:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/management/ThreadMXBean/ThreadLists.java on all configs. This pull request has now been integrated. Changeset: d40e90b4 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk18/commit/d40e90b4a1b55753a178d824c4c60209bc46efac Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8278521: ProblemList java/lang/management/ThreadMXBean/ThreadLists.java Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk18/pull/3 From jjg at openjdk.java.net Fri Dec 10 01:56:54 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 10 Dec 2021 01:56:54 GMT Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC Message-ID: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> Please review this semi-automatic update for the nroff man pages for JDK 18. The changes update the version number, copyright year, and incorporate the changes from the latest upstream files. ------------- Commit messages: - JDK-8273179: Update nroff pages in JDK 18 before RC Changes: https://git.openjdk.java.net/jdk18/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=5&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273179 Stats: 858 lines in 28 files changed: 448 ins; 146 del; 264 mod Patch: https://git.openjdk.java.net/jdk18/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/5/head:pull/5 PR: https://git.openjdk.java.net/jdk18/pull/5 From dholmes at openjdk.java.net Fri Dec 10 02:15:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 10 Dec 2021 02:15:33 GMT Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> Message-ID: On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons wrote: > Please review this semi-automatic update for the nroff man pages for JDK 18. The changes update the version number, copyright year, and incorporate the changes from the latest upstream files. Hi Jon, This all looks good - I'm familiar with many of the changes made to the sources but not yet generated. We will have to be careful not to regress the copyright year or version if any subsequent updates are made before next year, or before the version loses the EA designator. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/5 From jjg at openjdk.java.net Fri Dec 10 02:53:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 10 Dec 2021 02:53:14 GMT Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> Message-ID: <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com> On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons wrote: > Please review this semi-automatic update for the nroff man pages for JDK 18. The changes update the version number, copyright year, and incorporate the changes from the latest upstream files. Hi David, The copyright year will naturally sort itself out in a few weeks time ;-) When these changes make their way down from 18 to 19, we will probably want to regenerate these files with 19-EA. -- Jon We will also want to regenerate any appropriate files if any more updates to the man pages are made during the ramp down period. ------------- PR: https://git.openjdk.java.net/jdk18/pull/5 From jjg at openjdk.java.net Fri Dec 10 02:53:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 10 Dec 2021 02:53:14 GMT Subject: [jdk18] Integrated: JDK-8273179: Update nroff pages in JDK 18 before RC In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> Message-ID: On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons wrote: > Please review this semi-automatic update for the nroff man pages for JDK 18. The changes update the version number, copyright year, and incorporate the changes from the latest upstream files. This pull request has now been integrated. Changeset: ed5d53ae Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk18/commit/ed5d53ae0eb0b12de11fb3d79ae0371c093ce434 Stats: 858 lines in 28 files changed: 448 ins; 146 del; 264 mod 8273179: Update nroff pages in JDK 18 before RC Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk18/pull/5 From iris at openjdk.java.net Fri Dec 10 03:12:20 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 10 Dec 2021 03:12:20 GMT Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> Message-ID: <6aEQaagQdXw209dha2rqp32uSxtxze-f-1-j32dROQE=.53c0fcde-680f-40c6-bbc7-44a1e4635f11@github.com> On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons wrote: > Please review this semi-automatic update for the nroff man pages for JDK 18. The changes update the version number, copyright year, and incorporate the changes from the latest upstream files. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/5 From dholmes at openjdk.java.net Fri Dec 10 04:21:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 10 Dec 2021 04:21:18 GMT Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC In-Reply-To: <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com> References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com> Message-ID: On Fri, 10 Dec 2021 02:48:43 GMT, Jonathan Gibbons wrote: >> Please review this semi-automatic update for the nroff man pages for JDK 18. The changes update the version number, copyright year, and incorporate the changes from the latest upstream files. > > We will also want to regenerate any appropriate files if any more updates to the man pages are made during the ramp down period. Hi @jonathan-gibbons , I have a couple of manpage related tasks for early in the 19 release cycle that will take care of updating the version number. Unfortunately for this change it looks like whomever did the source uodate to the javadoc manpage did not know about the test: test/langtools/jdk/javadoc/tool/CheckManPageOptions.java which is now failing on all platforms. :( I will file a bug. David ------------- PR: https://git.openjdk.java.net/jdk18/pull/5 From jjg at openjdk.java.net Fri Dec 10 04:33:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 10 Dec 2021 04:33:14 GMT Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com> Message-ID: On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons wrote: > Please review this semi-automatic update for the nroff man pages for JDK 18. The changes update the version number, copyright year, and incorporate the changes from the latest upstream files. hmmm, I thought we had taken care of that test. I will investigate ------------- PR: https://git.openjdk.java.net/jdk18/pull/5 From cjplummer at openjdk.java.net Fri Dec 10 07:06:36 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 10 Dec 2021 07:06:36 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr Message-ID: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. ------------- Commit messages: - Retry heap dump if main thread stack trace is not present. Changes: https://git.openjdk.java.net/jdk/pull/6795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6795&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269556 Stats: 26 lines in 1 file changed: 19 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6795/head:pull/6795 PR: https://git.openjdk.java.net/jdk/pull/6795 From kevinw at openjdk.java.net Fri Dec 10 09:21:14 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 10 Dec 2021 09:21:14 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr In-Reply-To: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> Message-ID: On Fri, 10 Dec 2021 07:00:10 GMT, Chris Plummer wrote: > The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. Looks good. ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/6795 From sspitsyn at openjdk.java.net Fri Dec 10 12:25:13 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 10 Dec 2021 12:25:13 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr In-Reply-To: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> Message-ID: On Fri, 10 Dec 2021 07:00:10 GMT, Chris Plummer wrote: > The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. Hi Chris, It looks good in general. I feel the parameter 'retry' is a little bit confusing. It is possible to rename it to some to 'retriedOnce'. Another approach would be to name it 'allowRetry' and revert the meaning of boolean value. I leave it up to you to keep the original approach or make any change. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6795 From hseigel at openjdk.java.net Fri Dec 10 15:11:36 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 10 Dec 2021 15:11:36 GMT Subject: RFR: 8277481: Obsolete seldom used CDS flags Message-ID: Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64. The use of UseSharedSpaces in ps_core_common.c was tested on Mac OS x64 by temporarily removing serviceability/sa/ClhsdbPmap.java#core from the problem list. Thanks! Harold ------------- Commit messages: - fix typo - 8277481: Obsolete seldom used CDS flags Changes: https://git.openjdk.java.net/jdk/pull/6800/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6800&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277481 Stats: 151 lines in 13 files changed: 22 ins; 94 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/6800.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6800/head:pull/6800 PR: https://git.openjdk.java.net/jdk/pull/6800 From jwilhelm at openjdk.java.net Fri Dec 10 18:13:18 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 10 Dec 2021 18:13:18 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8277621: ARM32: multiple fastdebug failures with "bad AD file" after JDK-8276162 - 8278538: Test langtools/jdk/javadoc/tool/CheckManPageOptions.java fails after the manpage was updated - 8273179: Update nroff pages in JDK 18 before RC The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/6802/files Stats: 1142 lines in 30 files changed: 688 ins; 155 del; 299 mod Patch: https://git.openjdk.java.net/jdk/pull/6802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6802/head:pull/6802 PR: https://git.openjdk.java.net/jdk/pull/6802 From jwilhelm at openjdk.java.net Fri Dec 10 18:46:17 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 10 Dec 2021 18:46:17 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 17:51:31 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 61736f81 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/61736f81fb4a20375c83d59e2b37a00aafb11107 Stats: 1142 lines in 30 files changed: 688 ins; 155 del; 299 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/6802 From iklam at openjdk.java.net Fri Dec 10 19:10:15 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 10 Dec 2021 19:10:15 GMT Subject: RFR: 8277481: Obsolete seldom used CDS flags In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 15:01:29 GMT, Harold Seigel wrote: > Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64. > > The use of UseSharedSpaces in ps_core_common.c was tested on Mac OS x64 by temporarily removing serviceability/sa/ClhsdbPmap.java#core from the problem list. > > Thanks! Harold Looks good to me. Thanks for fixing this! ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6800 From ccheung at openjdk.java.net Fri Dec 10 19:41:16 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 10 Dec 2021 19:41:16 GMT Subject: RFR: 8277481: Obsolete seldom used CDS flags In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 15:01:29 GMT, Harold Seigel wrote: > Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64. > > The use of UseSharedSpaces in ps_core_common.c was tested on Mac OS x64 by temporarily removing serviceability/sa/ClhsdbPmap.java#core from the problem list. > > Thanks! Harold Looks good. Just one nit. src/jdk.hotspot.agent/share/native/libsaproc/ps_core_common.c line 303: > 301: useSharedSpacesAddr = lookup_symbol(ph, jvm_name, USE_SHARED_SPACES_SYM); > 302: if (useSharedSpacesAddr == 0) { > 303: print_debug("can't lookup 'UseSharedSpaces' symbol\n"); Maybe the `print_debug` at line 311 should also be updated from "flag" to "symbol"? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6800 From hseigel at openjdk.java.net Fri Dec 10 19:49:48 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 10 Dec 2021 19:49:48 GMT Subject: RFR: 8277481: Obsolete seldom used CDS flags [v2] In-Reply-To: References: Message-ID: > Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64. > > The use of UseSharedSpaces in ps_core_common.c was tested on Mac OS x64 by temporarily removing serviceability/sa/ClhsdbPmap.java#core from the problem list. > > Thanks! Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: fix print_debug() message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6800/files - new: https://git.openjdk.java.net/jdk/pull/6800/files/3f6c6dee..601a678f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6800&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6800&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6800.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6800/head:pull/6800 PR: https://git.openjdk.java.net/jdk/pull/6800 From hseigel at openjdk.java.net Fri Dec 10 19:49:51 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 10 Dec 2021 19:49:51 GMT Subject: RFR: 8277481: Obsolete seldom used CDS flags [v2] In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 19:37:31 GMT, Calvin Cheung wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix print_debug() message > > src/jdk.hotspot.agent/share/native/libsaproc/ps_core_common.c line 303: > >> 301: useSharedSpacesAddr = lookup_symbol(ph, jvm_name, USE_SHARED_SPACES_SYM); >> 302: if (useSharedSpacesAddr == 0) { >> 303: print_debug("can't lookup 'UseSharedSpaces' symbol\n"); > > Maybe the `print_debug` at line 311 should also be updated from "flag" to "symbol"? fixed. Thanks for pointing it out. ------------- PR: https://git.openjdk.java.net/jdk/pull/6800 From cjplummer at openjdk.java.net Fri Dec 10 20:30:41 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 10 Dec 2021 20:30:41 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr [v2] In-Reply-To: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> Message-ID: <9dxbkrrGQv3cAErz0h-3hVUXLpu-9EbDXKBW4O-ujeE=.6ac19a8c-5054-4506-9391-564540f721e9@github.com> > The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Renamed isRetry to allowRetry. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6795/files - new: https://git.openjdk.java.net/jdk/pull/6795/files/65e14883..aaa915b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6795&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6795&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6795/head:pull/6795 PR: https://git.openjdk.java.net/jdk/pull/6795 From cjplummer at openjdk.java.net Fri Dec 10 20:30:44 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 10 Dec 2021 20:30:44 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr [v2] In-Reply-To: References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> Message-ID: On Fri, 10 Dec 2021 12:22:22 GMT, Serguei Spitsyn wrote: > Hi Chris, > It looks good in general. I feel the parameter 'retry' is a little bit confusing. It is possible to rename it to some to 'retriedOnce'. Another approach would be to name it 'allowRetry' and revert the meaning of boolean value. > I leave it up to you to keep the original approach or make any change. > Thanks, > Serguei Ok. I changed it to allowRetry. ------------- PR: https://git.openjdk.java.net/jdk/pull/6795 From amenkov at openjdk.java.net Fri Dec 10 21:12:49 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 10 Dec 2021 21:12:49 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr [v2] In-Reply-To: <9dxbkrrGQv3cAErz0h-3hVUXLpu-9EbDXKBW4O-ujeE=.6ac19a8c-5054-4506-9391-564540f721e9@github.com> References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> <9dxbkrrGQv3cAErz0h-3hVUXLpu-9EbDXKBW4O-ujeE=.6ac19a8c-5054-4506-9391-564540f721e9@github.com> Message-ID: On Fri, 10 Dec 2021 20:30:41 GMT, Chris Plummer wrote: >> The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Renamed isRetry to allowRetry. Changes requested by amenkov (Reviewer). test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 112: > 110: // if that happens. This failure is so rare that this should be enough to make it > 111: // extremely unlikely that we ever see this test fail again for this reason. > 112: if (allowRetry) { Looks like this should be !allowRetry ------------- PR: https://git.openjdk.java.net/jdk/pull/6795 From cjplummer at openjdk.java.net Fri Dec 10 21:12:45 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 10 Dec 2021 21:12:45 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr [v3] In-Reply-To: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> Message-ID: > The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Fix allowRetry reference. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6795/files - new: https://git.openjdk.java.net/jdk/pull/6795/files/aaa915b3..8be1552a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6795&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6795&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6795/head:pull/6795 PR: https://git.openjdk.java.net/jdk/pull/6795 From cjplummer at openjdk.java.net Fri Dec 10 21:12:52 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 10 Dec 2021 21:12:52 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr [v2] In-Reply-To: References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> <9dxbkrrGQv3cAErz0h-3hVUXLpu-9EbDXKBW4O-ujeE=.6ac19a8c-5054-4506-9391-564540f721e9@github.com> Message-ID: <4GnhMi91TclaeGKNVja9GQWIU3QF0jS1QJmvDjexvWc=.234c228a-80a7-456c-b74e-a3f466d2268b@github.com> On Fri, 10 Dec 2021 21:05:38 GMT, Alex Menkov wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed isRetry to allowRetry. > > test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 112: > >> 110: // if that happens. This failure is so rare that this should be enough to make it >> 111: // extremely unlikely that we ever see this test fail again for this reason. >> 112: if (allowRetry) { > > Looks like this should be !allowRetry Yeah, I was just looking at the diff an noticed that, but you beat me to it. Will push another commit to fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/6795 From amenkov at openjdk.java.net Fri Dec 10 21:22:18 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 10 Dec 2021 21:22:18 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr [v3] In-Reply-To: References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> Message-ID: On Fri, 10 Dec 2021 21:12:45 GMT, Chris Plummer wrote: >> The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix allowRetry reference. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6795 From sspitsyn at openjdk.java.net Fri Dec 10 22:43:10 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 10 Dec 2021 22:43:10 GMT Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr [v3] In-Reply-To: References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> Message-ID: On Fri, 10 Dec 2021 21:12:45 GMT, Chris Plummer wrote: >> The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix allowRetry reference. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6795 From dholmes at openjdk.java.net Sun Dec 12 23:20:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 12 Dec 2021 23:20:10 GMT Subject: RFR: 8277481: Obsolete seldom used CDS flags [v2] In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 19:49:48 GMT, Harold Seigel wrote: >> Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64. >> >> The use of UseSharedSpaces in ps_core_common.c was tested on Mac OS x64 by temporarily removing serviceability/sa/ClhsdbPmap.java#core from the problem list. >> >> Thanks! Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix print_debug() message LGTM! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6800 From dholmes at openjdk.java.net Mon Dec 13 04:32:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 13 Dec 2021 04:32:42 GMT Subject: [jdk18] RFR: 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently Message-ID: Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures. Testing: local and tier3. Thanks, David ------------- Commit messages: - Fixed tab character - 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently Changes: https://git.openjdk.java.net/jdk18/pull/14/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=14&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8132785 Stats: 23 lines in 2 files changed: 20 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk18/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/14/head:pull/14 PR: https://git.openjdk.java.net/jdk18/pull/14 From alanb at openjdk.java.net Mon Dec 13 09:29:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 13 Dec 2021 09:29:08 GMT Subject: [jdk18] RFR: 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 04:19:39 GMT, David Holmes wrote: > Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures. > > Testing: local and tier3. > > Thanks, > David Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/14 From kevinw at openjdk.java.net Mon Dec 13 11:05:09 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 13 Dec 2021 11:05:09 GMT Subject: [jdk18] RFR: 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 04:19:39 GMT, David Holmes wrote: > Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures. > > Testing: local and tier3. > > Thanks, > David Yes, othervm and printing the threads from both points of view looks good. 8-) ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk18/pull/14 From hseigel at openjdk.java.net Mon Dec 13 13:38:17 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 13 Dec 2021 13:38:17 GMT Subject: RFR: 8277481: Obsolete seldom used CDS flags [v2] In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 19:49:48 GMT, Harold Seigel wrote: >> Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64. >> >> The use of UseSharedSpaces in ps_core_common.c was tested on Mac OS x64 by temporarily removing serviceability/sa/ClhsdbPmap.java#core from the problem list. >> >> Thanks! Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix print_debug() message Thanks Ioi, Calvin, and David for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/6800 From hseigel at openjdk.java.net Mon Dec 13 13:38:17 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 13 Dec 2021 13:38:17 GMT Subject: Integrated: 8277481: Obsolete seldom used CDS flags In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 15:01:29 GMT, Harold Seigel wrote: > Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64. > > The use of UseSharedSpaces in ps_core_common.c was tested on Mac OS x64 by temporarily removing serviceability/sa/ClhsdbPmap.java#core from the problem list. > > Thanks! Harold This pull request has now been integrated. Changeset: 14f7385a Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/14f7385a72972e1f15b3103cc75a60c5733f6d98 Stats: 152 lines in 13 files changed: 22 ins; 94 del; 36 mod 8277481: Obsolete seldom used CDS flags Reviewed-by: iklam, ccheung, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6800 From dcubed at openjdk.java.net Mon Dec 13 15:27:21 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 13 Dec 2021 15:27:21 GMT Subject: [jdk18] RFR: 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently In-Reply-To: References: Message-ID: <-JbF2kBndr-7f9WEH9tooMVxVi6Wb1fSWzQpgC0YfcQ=.ca980ed0-099b-409c-b670-7a9d04c6fcd0@github.com> On Mon, 13 Dec 2021 04:19:39 GMT, David Holmes wrote: > Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures. > > Testing: local and tier3. > > Thanks, > David Thumbs up. Thanks for including a comment about why othervm is needed. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/14 From cjplummer at openjdk.java.net Mon Dec 13 19:05:17 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 13 Dec 2021 19:05:17 GMT Subject: Integrated: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr In-Reply-To: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com> Message-ID: On Fri, 10 Dec 2021 07:00:10 GMT, Chris Plummer wrote: > The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. This pull request has now been integrated. Changeset: db502d30 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/db502d30a42847f69273f48378f230d9d55eb8d6 Stats: 26 lines in 1 file changed: 19 ins; 0 del; 7 mod 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr Reviewed-by: kevinw, sspitsyn, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/6795 From sspitsyn at openjdk.java.net Mon Dec 13 21:32:20 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 13 Dec 2021 21:32:20 GMT Subject: [jdk18] RFR: 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 04:19:39 GMT, David Holmes wrote: > Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures. > > Testing: local and tier3. > > Thanks, > David Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/14 From dholmes at openjdk.java.net Mon Dec 13 21:40:27 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 13 Dec 2021 21:40:27 GMT Subject: [jdk18] RFR: 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 04:19:39 GMT, David Holmes wrote: > Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures. > > Testing: local and tier3. > > Thanks, > David Thanks for all the reviews! ------------- PR: https://git.openjdk.java.net/jdk18/pull/14 From dholmes at openjdk.java.net Mon Dec 13 21:40:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 13 Dec 2021 21:40:28 GMT Subject: [jdk18] Integrated: 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently In-Reply-To: References: Message-ID: <3HJGz-gnxjRAgqKxorMHrDafeXfRcZfJFD2sJbFdj4M=.de8d7e37-9e97-4182-b4a7-f8429244e9f5@github.com> On Mon, 13 Dec 2021 04:19:39 GMT, David Holmes wrote: > Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures. > > Testing: local and tier3. > > Thanks, > David This pull request has now been integrated. Changeset: c93b24d8 Author: David Holmes URL: https://git.openjdk.java.net/jdk18/commit/c93b24d85289167639e9ec4b79bd85403687161b Stats: 23 lines in 2 files changed: 20 ins; 1 del; 2 mod 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently Reviewed-by: alanb, kevinw, dcubed, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk18/pull/14 From coleenp at openjdk.java.net Mon Dec 13 23:22:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 13 Dec 2021 23:22:42 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation Message-ID: This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug and linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). ------------- Commit messages: - Refactor cpu_name, etc into abstract_vm_version. - 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation Changes: https://git.openjdk.java.net/jdk/pull/6820/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6820&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202579 Stats: 2972 lines in 33 files changed: 1105 ins; 1830 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/6820.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6820/head:pull/6820 PR: https://git.openjdk.java.net/jdk/pull/6820 From cjplummer at openjdk.java.net Tue Dec 14 00:55:38 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 14 Dec 2021 00:55:38 GMT Subject: RFR: 8244765: Undo exclusiveAccess.dirs changes for JDK-8220295 and see if there are still any testing issues Message-ID: This changes removes (most) Attach API tests from exclusiveAccess.dirs so the tests can be run in parallel. I haven't seen any issues with this change, except the jstatd tests can fail due to an RMI issue. I filed https://bugs.openjdk.java.net/browse/JDK-8278625 to cover that issue. ------------- Commit messages: - Move most attach api stests from exclusiveAccess.dirs Changes: https://git.openjdk.java.net/jdk/pull/6818/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6818&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244765 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6818.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6818/head:pull/6818 PR: https://git.openjdk.java.net/jdk/pull/6818 From amenkov at openjdk.java.net Tue Dec 14 01:06:24 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 14 Dec 2021 01:06:24 GMT Subject: RFR: 8244765: Undo exclusiveAccess.dirs changes for JDK-8220295 and see if there are still any testing issues In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 21:00:02 GMT, Chris Plummer wrote: > This changes removes (most) Attach API tests from exclusiveAccess.dirs so the tests can be run in parallel. I haven't seen any issues with this change, except the jstatd tests can fail due to an RMI issue. I filed https://bugs.openjdk.java.net/browse/JDK-8278625 to cover that issue. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6818 From cjplummer at openjdk.java.net Tue Dec 14 01:21:43 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 14 Dec 2021 01:21:43 GMT Subject: RFR: 8278643: CoreUtils.getCoreFileLocation() should print out the size of the core file found Message-ID: Include the size of the core file when printing a message that it was found. ------------- Commit messages: - Print the size of the core file found Changes: https://git.openjdk.java.net/jdk/pull/6822/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6822&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278643 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6822/head:pull/6822 PR: https://git.openjdk.java.net/jdk/pull/6822 From amenkov at openjdk.java.net Tue Dec 14 01:41:13 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 14 Dec 2021 01:41:13 GMT Subject: RFR: 8278643: CoreUtils.getCoreFileLocation() should print out the size of the core file found In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 01:14:45 GMT, Chris Plummer wrote: > Include the size of the core file when printing a message that it was found. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6822 From jwilhelm at openjdk.java.net Tue Dec 14 01:49:19 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 14 Dec 2021 01:49:19 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently - 8273108: RunThese24H crashes with SEGV in markWord::displaced_mark_helper() after JDK-8268276 - 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64 - 8277299: STACK_OVERFLOW in Java_sun_awt_shell_Win32ShellFolder2_getIconBits The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/6824/files Stats: 119 lines in 6 files changed: 85 ins; 1 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/6824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6824/head:pull/6824 PR: https://git.openjdk.java.net/jdk/pull/6824 From lmesnik at openjdk.java.net Tue Dec 14 01:51:14 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 14 Dec 2021 01:51:14 GMT Subject: RFR: 8278643: CoreUtils.getCoreFileLocation() should print out the size of the core file found In-Reply-To: References: Message-ID: <01wZd9_-BolXB5Wo-uQOJ7j-7WRdpnX11z6BziD_w9o=.cf457434-fa1f-4a6a-81be-15c1d30f5dae@github.com> On Tue, 14 Dec 2021 01:14:45 GMT, Chris Plummer wrote: > Include the size of the core file when printing a message that it was found. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6822 From jwilhelm at openjdk.java.net Tue Dec 14 02:21:17 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 14 Dec 2021 02:21:17 GMT Subject: RFR: Merge jdk18 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 18 -> JDK 19 Jesper Wilhelmsson 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 29 additional commits since the last revision: - Merge - 8278275: Initial nroff manpage generation for JDK 19 Reviewed-by: erikj, jjg, iris - 8278630: ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64 Reviewed-by: psandoz - 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr Reviewed-by: kevinw, sspitsyn, amenkov - 8259610: VectorReshapeTests are not effective due to failing to intrinsify "VectorSupport.convert" Reviewed-by: psandoz, chagedorn - 8276241: JVM does not flag constant class entries ending in '/' Reviewed-by: dholmes, lfoltan - 8277481: Obsolete seldom used CDS flags Reviewed-by: iklam, ccheung, dholmes - 8271079: JavaFileObject#toUri and multi-release jars Reviewed-by: jjg, lancea, alanb - 8278482: G1: Improve HeapRegion::block_is_obj Reviewed-by: sjohanss, tschatzl, mli - 8278344: sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of different openssl output Reviewed-by: mdoerr, goetz, stuefe - ... and 19 more: https://git.openjdk.java.net/jdk/compare/9d2883a1...dc02f07e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6824/files - new: https://git.openjdk.java.net/jdk/pull/6824/files/dc02f07e..dc02f07e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6824&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6824&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6824/head:pull/6824 PR: https://git.openjdk.java.net/jdk/pull/6824 From jwilhelm at openjdk.java.net Tue Dec 14 02:21:19 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 14 Dec 2021 02:21:19 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 01:35:43 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 8401a059 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/8401a059bd01b32e3532f806d3d8b60e851c468a Stats: 119 lines in 6 files changed: 85 ins; 1 del; 33 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/6824 From dholmes at openjdk.java.net Tue Dec 14 02:53:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 14 Dec 2021 02:53:13 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation In-Reply-To: References: Message-ID: <1XdDFHOWs-V8LCU8RhRL2ZH3E9l7WM_vI_QRZCoOcaw=.7e8cb129-046e-45d7-887e-ea2669c77d33@github.com> On Mon, 13 Dec 2021 23:14:43 GMT, Coleen Phillimore wrote: > This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. > > Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: > linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug > and > linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug > > Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). Hi Coleen, The code relocation seems okay. Good cleanup! One query below on `CPUInformationInterface::initialize()`. Good catch on the `Abstract_VM_Version` calls in jvm.cpp! I missed that in the review of JDK-8241071. Thanks, David src/hotspot/os/linux/os_perf_linux.cpp line 929: > 927: bool CPUInformationInterface::initialize() { > 928: _cpu_info = new CPUInformation(); > 929: VM_Version::initialize_cpu_information(); I can't figure out when this code will actually get executed in relation to the VM initialization process and VM_Version's initialization. Can this actually execute before that happens? Or could we assert that it has happened? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6820 From cjplummer at openjdk.java.net Tue Dec 14 03:17:43 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 14 Dec 2021 03:17:43 GMT Subject: RFR: 8273904: debug agent ArrayTypeImp::newInstance() fails to send reply packet if there is an error Message-ID: ArrayTypeImp::newInstance() was returning false instead of true for one error condition, resulting in a failure to send a reply packet containing the error. See the bug description for details. ------------- Commit messages: - ArrayTypeImp::newInstance() should always return true, even if there is an error. Changes: https://git.openjdk.java.net/jdk/pull/6825/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6825&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273904 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6825.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6825/head:pull/6825 PR: https://git.openjdk.java.net/jdk/pull/6825 From cjplummer at openjdk.java.net Tue Dec 14 07:10:31 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 14 Dec 2021 07:10:31 GMT Subject: RFR: 8269838: BasicTypeDataBase.findDynamicTypeForAddress(addr, basetype) can be simplified Message-ID: SA had a bunch of vtable related code that searched for the vtable pointer of a hotspot object in a few places. This was all related to weird ways that Solaris would store the vtable pointer. In the case of https://bugs.openjdk.java.net/browse/JDK-8269830, this extra vtable searching code introduced a bug in BasicTypeDataBase.addressTypeIsEqualToType(). Since we don't support Solaris anymore, this the bug was fixed by removing this Solaris support. At the time I fixed JDK-8269830, I noticed that BasicTypeDataBase.findDynamicTypeForAddress() had similar logic for vtable searching, although didn't seemed to be causing any bugs at the time. I filed JDK-8269838 to eventually clean it up, and that's what this PR is doing. ------------- Commit messages: - Strip out code that looks for vtable pointers in locations other than the 1st word of the object. Changes: https://git.openjdk.java.net/jdk/pull/6827/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6827&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269838 Stats: 36 lines in 1 file changed: 0 ins; 28 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6827/head:pull/6827 PR: https://git.openjdk.java.net/jdk/pull/6827 From sspitsyn at openjdk.java.net Tue Dec 14 10:00:13 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 14 Dec 2021 10:00:13 GMT Subject: RFR: 8244765: Undo exclusiveAccess.dirs changes for JDK-8220295 and see if there are still any testing issues In-Reply-To: References: Message-ID: <9za_ufCEF6lAFBCPzpdRYArGnuOP431YD4aW2yfROZQ=.236884ad-655a-427e-8f75-52746919278f@github.com> On Mon, 13 Dec 2021 21:00:02 GMT, Chris Plummer wrote: > This changes removes (most) Attach API tests from exclusiveAccess.dirs so the tests can be run in parallel. I haven't seen any issues with this change, except the jstatd tests can fail due to an RMI issue. I filed https://bugs.openjdk.java.net/browse/JDK-8278625 to cover that issue, and left jstatd tests in exclusiveAccess.dirs. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6818 From sspitsyn at openjdk.java.net Tue Dec 14 10:03:13 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 14 Dec 2021 10:03:13 GMT Subject: RFR: 8278643: CoreUtils.getCoreFileLocation() should print out the size of the core file found In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 01:14:45 GMT, Chris Plummer wrote: > Include the size of the core file when printing a message that it was found. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6822 From sspitsyn at openjdk.java.net Tue Dec 14 10:21:15 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 14 Dec 2021 10:21:15 GMT Subject: RFR: 8273904: debug agent ArrayTypeImp::newInstance() fails to send reply packet if there is an error In-Reply-To: References: Message-ID: <9Dz74-jjka2kijEI1ls5dZk36v1STlQUTXI1h5Tz_VA=.3138b00e-96cd-488a-bf67-81641b845289@github.com> On Tue, 14 Dec 2021 03:10:00 GMT, Chris Plummer wrote: > ArrayTypeImp::newInstance() was returning false instead of true for one error condition, resulting in a failure to send a reply packet containing the error. See the bug description for details. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6825 From kevinw at openjdk.java.net Tue Dec 14 10:45:11 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 14 Dec 2021 10:45:11 GMT Subject: RFR: 8269838: BasicTypeDataBase.findDynamicTypeForAddress(addr, basetype) can be simplified In-Reply-To: References: Message-ID: <_fkj3xQy_25FiPJD5nZPeZBQOe6gEMJ8WOwQJ1GEE1o=.d97ec87e-8f4d-4e67-a92d-fd4a514354c9@github.com> On Tue, 14 Dec 2021 06:57:36 GMT, Chris Plummer wrote: > SA had a bunch of vtable related code that searched for the vtable pointer of a hotspot object in a few places. This was all related to weird ways that Solaris would store the vtable pointer. In the case of https://bugs.openjdk.java.net/browse/JDK-8269830, this extra vtable searching code introduced a bug in BasicTypeDataBase.addressTypeIsEqualToType(). Since we don't support Solaris anymore, this the bug was fixed by removing this Solaris support. At the time I fixed JDK-8269830, I noticed that BasicTypeDataBase.findDynamicTypeForAddress() had similar logic for vtable searching, although didn't seemed to be causing any bugs at the time. I filed JDK-8269838 to eventually clean it up, and that's what this PR is doing. First word of object is the only sensible place for the vtable pointer... 8-) ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/6827 From coleenp at openjdk.java.net Tue Dec 14 16:29:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 14 Dec 2021 16:29:09 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 23:14:43 GMT, Coleen Phillimore wrote: > This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. > > Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: > linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug > and > linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug > > Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). Thanks for the review, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/6820 From coleenp at openjdk.java.net Tue Dec 14 16:29:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 14 Dec 2021 16:29:10 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation In-Reply-To: <1XdDFHOWs-V8LCU8RhRL2ZH3E9l7WM_vI_QRZCoOcaw=.7e8cb129-046e-45d7-887e-ea2669c77d33@github.com> References: <1XdDFHOWs-V8LCU8RhRL2ZH3E9l7WM_vI_QRZCoOcaw=.7e8cb129-046e-45d7-887e-ea2669c77d33@github.com> Message-ID: On Tue, 14 Dec 2021 02:32:54 GMT, David Holmes wrote: >> This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. >> >> Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: >> linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug >> and >> linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug >> >> Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). > > src/hotspot/os/linux/os_perf_linux.cpp line 929: > >> 927: bool CPUInformationInterface::initialize() { >> 928: _cpu_info = new CPUInformation(); >> 929: VM_Version::initialize_cpu_information(); > > I can't figure out when this code will actually get executed in relation to the VM initialization process and VM_Version's initialization. Can this actually execute before that happens? Or could we assert that it has happened? VM_Version::initialize() is called very early in Threads::create_vm. This latter VM_Version::initialize_cpu_information is called later when JFR event is emitted. The reason it was "_ext" was because it is part of JFR only. It seems that we might be able to consolidate this more now that it's moved later. I don't think adding an assert would be meaningful here. ------------- PR: https://git.openjdk.java.net/jdk/pull/6820 From coleenp at openjdk.java.net Tue Dec 14 17:42:00 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 14 Dec 2021 17:42:00 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation [v2] In-Reply-To: References: Message-ID: > This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. > > Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: > linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug > and > linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug > > Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Added an initialization assert. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6820/files - new: https://git.openjdk.java.net/jdk/pull/6820/files/e611acb4..569896e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6820&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6820&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6820.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6820/head:pull/6820 PR: https://git.openjdk.java.net/jdk/pull/6820 From coleenp at openjdk.java.net Tue Dec 14 17:42:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 14 Dec 2021 17:42:05 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation [v2] In-Reply-To: References: <1XdDFHOWs-V8LCU8RhRL2ZH3E9l7WM_vI_QRZCoOcaw=.7e8cb129-046e-45d7-887e-ea2669c77d33@github.com> Message-ID: On Tue, 14 Dec 2021 16:24:10 GMT, Coleen Phillimore wrote: >> src/hotspot/os/linux/os_perf_linux.cpp line 929: >> >>> 927: bool CPUInformationInterface::initialize() { >>> 928: _cpu_info = new CPUInformation(); >>> 929: VM_Version::initialize_cpu_information(); >> >> I can't figure out when this code will actually get executed in relation to the VM initialization process and VM_Version's initialization. Can this actually execute before that happens? Or could we assert that it has happened? > > VM_Version::initialize() is called very early in Threads::create_vm. This latter VM_Version::initialize_cpu_information is called later when JFR event is emitted. The reason it was "_ext" was because it is part of JFR only. It seems that we might be able to consolidate this more later now that it's moved together. > I don't think adding an assert would be meaningful here. I did add a simple initialization assert in the x86 code where it might be interesting and reran the JFR tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/6820 From amenkov at openjdk.java.net Tue Dec 14 20:01:18 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 14 Dec 2021 20:01:18 GMT Subject: RFR: 8273904: debug agent ArrayTypeImp::newInstance() fails to send reply packet if there is an error In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 03:10:00 GMT, Chris Plummer wrote: > ArrayTypeImp::newInstance() was returning false instead of true for one error condition, resulting in a failure to send a reply packet containing the error. See the bug description for details. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6825 From hseigel at openjdk.java.net Tue Dec 14 20:22:00 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 14 Dec 2021 20:22:00 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 17:42:00 GMT, Coleen Phillimore wrote: >> This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. >> >> Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: >> linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug >> and >> linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug >> >> Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Added an initialization assert. Thanks for doing this! Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6820 From sspitsyn at openjdk.java.net Tue Dec 14 21:33:00 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 14 Dec 2021 21:33:00 GMT Subject: RFR: 8269838: BasicTypeDataBase.findDynamicTypeForAddress(addr, basetype) can be simplified In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 06:57:36 GMT, Chris Plummer wrote: > SA had a bunch of vtable related code that searched for the vtable pointer of a hotspot object in a few places. This was all related to weird ways that Solaris would store the vtable pointer. In the case of https://bugs.openjdk.java.net/browse/JDK-8269830, this extra vtable searching code introduced a bug in BasicTypeDataBase.addressTypeIsEqualToType(). Since we don't support Solaris anymore, this the bug was fixed by removing this Solaris support. At the time I fixed JDK-8269830, I noticed that BasicTypeDataBase.findDynamicTypeForAddress() had similar logic for vtable searching, although didn't seemed to be causing any bugs at the time. I filed JDK-8269838 to eventually clean it up, and that's what this PR is doing. Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6827 From coleenp at openjdk.java.net Tue Dec 14 23:31:00 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 14 Dec 2021 23:31:00 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation [v2] In-Reply-To: References: Message-ID: <1cNfNfX75OoH6vniMzrDpVFOuMwQ8y-gDbOyppYvKyw=.d23a5d9a-abaf-4f6c-b77d-67f71e67fd63@github.com> On Tue, 14 Dec 2021 17:42:00 GMT, Coleen Phillimore wrote: >> This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. >> >> Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: >> linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug >> and >> linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug >> >> Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Added an initialization assert. Thanks for reviewing, Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/6820 From dholmes at openjdk.java.net Wed Dec 15 01:19:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Dec 2021 01:19:00 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation [v2] In-Reply-To: References: Message-ID: <1b76ouVvE4CqegpZSEyBqgRctNPV2Xo04zRZkFyXrlA=.4590760e-56c7-4158-8861-f508e74e8ce8@github.com> On Tue, 14 Dec 2021 17:42:00 GMT, Coleen Phillimore wrote: >> This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. >> >> Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: >> linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug >> and >> linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug >> >> Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Added an initialization assert. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6820 From cjplummer at openjdk.java.net Wed Dec 15 01:29:02 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 15 Dec 2021 01:29:02 GMT Subject: Integrated: 8278643: CoreUtils.getCoreFileLocation() should print out the size of the core file found In-Reply-To: References: Message-ID: <88d-VjZwQ3UskIm7_SJApSX_LjyoPzr3kIkw_udybh8=.27081d03-af8b-4a62-a9d2-ea012745cc67@github.com> On Tue, 14 Dec 2021 01:14:45 GMT, Chris Plummer wrote: > Include the size of the core file when printing a message that it was found. This pull request has now been integrated. Changeset: 54c9a996 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/54c9a99663c47b0477392a606637986bc5c87464 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8278643: CoreUtils.getCoreFileLocation() should print out the size of the core file found Reviewed-by: amenkov, lmesnik, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6822 From cjplummer at openjdk.java.net Wed Dec 15 01:32:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 15 Dec 2021 01:32:59 GMT Subject: Integrated: 8244765: Undo exclusiveAccess.dirs changes for JDK-8220295 and see if there are still any testing issues In-Reply-To: References: Message-ID: <2UoK5zbrWoJp5_2yABaOKBRKGID0HE0b8GLIE88RhHQ=.64064432-de65-4bcb-a38f-34e908c3d995@github.com> On Mon, 13 Dec 2021 21:00:02 GMT, Chris Plummer wrote: > This changes removes (most) Attach API tests from exclusiveAccess.dirs so the tests can be run in parallel. I haven't seen any issues with this change, except the jstatd tests can fail due to an RMI issue. I filed https://bugs.openjdk.java.net/browse/JDK-8278625 to cover that issue, and left jstatd tests in exclusiveAccess.dirs. This pull request has now been integrated. Changeset: 46f99aca Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/46f99aca94ed878a94878eacb113fe2813050ad7 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8244765: Undo exclusiveAccess.dirs changes for JDK-8220295 and see if there are still any testing issues Reviewed-by: amenkov, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6818 From cjplummer at openjdk.java.net Wed Dec 15 03:15:00 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 15 Dec 2021 03:15:00 GMT Subject: Integrated: 8273904: debug agent ArrayTypeImp::newInstance() fails to send reply packet if there is an error In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 03:10:00 GMT, Chris Plummer wrote: > ArrayTypeImp::newInstance() was returning false instead of true for one error condition, resulting in a failure to send a reply packet containing the error. See the bug description for details. This pull request has now been integrated. Changeset: 758fe9be Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/758fe9bed3daf9a31d15291ef9787dc5a914451f Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8273904: debug agent ArrayTypeImp::newInstance() fails to send reply packet if there is an error Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/6825 From cjplummer at openjdk.java.net Wed Dec 15 03:16:17 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 15 Dec 2021 03:16:17 GMT Subject: RFR: 8276982: VM.class_hierarchy jcmd help output and man page text needs clarifications/improvements Message-ID: Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page. ------------- Commit messages: - Fix VM.class_hierarchy help output and man page. Changes: https://git.openjdk.java.net/jdk/pull/6845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276982 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6845/head:pull/6845 PR: https://git.openjdk.java.net/jdk/pull/6845 From stuefe at openjdk.java.net Wed Dec 15 05:56:58 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 15 Dec 2021 05:56:58 GMT Subject: RFR: 8276982: VM.class_hierarchy jcmd help output and man page text needs clarifications/improvements In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 03:08:40 GMT, Chris Plummer wrote: > Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page. Looks good and trivial. Thanks, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6845 From dholmes at openjdk.java.net Wed Dec 15 06:54:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Dec 2021 06:54:58 GMT Subject: RFR: 8276982: VM.class_hierarchy jcmd help output and man page text needs clarifications/improvements In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 03:08:40 GMT, Chris Plummer wrote: > Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page. LGTM 2. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6845 From sspitsyn at openjdk.java.net Wed Dec 15 07:33:00 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 15 Dec 2021 07:33:00 GMT Subject: RFR: 8276982: VM.class_hierarchy jcmd help output and man page text needs clarifications/improvements In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 03:08:40 GMT, Chris Plummer wrote: > Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6845 From coleenp at openjdk.java.net Wed Dec 15 13:49:01 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 15 Dec 2021 13:49:01 GMT Subject: RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 17:42:00 GMT, Coleen Phillimore wrote: >> This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. >> >> Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: >> linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug >> and >> linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug >> >> Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Added an initialization assert. Thanks for the re-review, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/6820 From coleenp at openjdk.java.net Wed Dec 15 13:49:02 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 15 Dec 2021 13:49:02 GMT Subject: Integrated: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 23:14:43 GMT, Coleen Phillimore wrote: > This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code. x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change. > > Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on: > linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug > and > linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug > > Ran JFR tests manually (it uses os_perf* CPUInformationInterface code). This pull request has now been integrated. Changeset: 1e3ae3be Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/1e3ae3be02e1fa76c632ef289dd1887c7fa369ec Stats: 2976 lines in 33 files changed: 1109 ins; 1830 del; 37 mod 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation Reviewed-by: dholmes, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/6820 From cjplummer at openjdk.java.net Wed Dec 15 17:11:58 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 15 Dec 2021 17:11:58 GMT Subject: Integrated: 8269838: BasicTypeDataBase.findDynamicTypeForAddress(addr, basetype) can be simplified In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 06:57:36 GMT, Chris Plummer wrote: > SA had a bunch of vtable related code that searched for the vtable pointer of a hotspot object in a few places. This was all related to weird ways that Solaris would store the vtable pointer. In the case of https://bugs.openjdk.java.net/browse/JDK-8269830, this extra vtable searching code introduced a bug in BasicTypeDataBase.addressTypeIsEqualToType(). Since we don't support Solaris anymore, this the bug was fixed by removing this Solaris support. At the time I fixed JDK-8269830, I noticed that BasicTypeDataBase.findDynamicTypeForAddress() had similar logic for vtable searching, although didn't seemed to be causing any bugs at the time. I filed JDK-8269838 to eventually clean it up, and that's what this PR is doing. This pull request has now been integrated. Changeset: 7517c85d Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/7517c85da3236e5274580645d4c3cdecb1db25c5 Stats: 36 lines in 1 file changed: 0 ins; 28 del; 8 mod 8269838: BasicTypeDataBase.findDynamicTypeForAddress(addr, basetype) can be simplified Reviewed-by: kevinw, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6827 From duke at openjdk.java.net Wed Dec 15 18:03:02 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 15 Dec 2021 18:03:02 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance > @turbanoff Only [Committers](https://openjdk.java.net/bylaws#committer) are allowed to sponsor changes. But I am a Committer ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From duke at openjdk.java.net Wed Dec 15 19:32:04 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 15 Dec 2021 19:32:04 GMT Subject: Integrated: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance This pull request has now been integrated. Changeset: 04dbdd36 Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/04dbdd36dd04bf40737cb8c2f13d5b75303d2b1a Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod 8274898: Cleanup usages of StringBuffer in jdk tools modules Reviewed-by: sspitsyn, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From dholmes at openjdk.java.net Wed Dec 15 21:41:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Dec 2021 21:41:02 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 17:59:54 GMT, Andrey Turbanov wrote: > > @turbanoff Only [Committers](https://openjdk.java.net/bylaws#committer) are allowed to sponsor changes. > > But I am a Committer ?? You can't "sponsor" your own change. I suspect your Committer status changed after the bot initially checked your status way back in September. Not sure how often the bot will recheck that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From hseigel at openjdk.java.net Thu Dec 16 17:46:33 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 16 Dec 2021 17:46:33 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string Message-ID: Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. Thanks! Harold ------------- Commit messages: - 8225093: Special property jdk.boot.class.path.append should not default to empty string Changes: https://git.openjdk.java.net/jdk/pull/6868/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225093 Stats: 116 lines in 4 files changed: 114 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6868/head:pull/6868 PR: https://git.openjdk.java.net/jdk/pull/6868 From enikitin at openjdk.java.net Thu Dec 16 20:20:41 2021 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Thu, 16 Dec 2021 20:20:41 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: References: Message-ID: <0_iROrhelCBAS2sNgY6vkvDjCq0sh_5skuY41Zi_Lhg=.a1f21483-cdc1-40cd-98c3-c93adbdacbdb@github.com> > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. Evgeny Nikitin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Get rid of while-breaks - Add JIT requirements - Remove explicit type specifiers for own class static calls - Remove redundant build directive - Merge branch 'master' into JDK-8274982/public - 8274982: Add a test for 8269574. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5889/files - new: https://git.openjdk.java.net/jdk/pull/5889/files/3d2dfed9..6336f6af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5889&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5889&range=00-01 Stats: 980305 lines in 3370 files changed: 519681 ins; 440480 del; 20144 mod Patch: https://git.openjdk.java.net/jdk/pull/5889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5889/head:pull/5889 PR: https://git.openjdk.java.net/jdk/pull/5889 From enikitin at openjdk.java.net Thu Dec 16 20:20:49 2021 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Thu, 16 Dec 2021 20:20:49 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 05:56:37 GMT, David Holmes wrote: >> Evgeny Nikitin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Get rid of while-breaks >> - Add JIT requirements >> - Remove explicit type specifiers for own class static calls >> - Remove redundant build directive >> - Merge branch 'master' into JDK-8274982/public >> - 8274982: Add a test for 8269574. > > test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 28: > >> 26: * @bug 8269574 >> 27: * @summary Verifies that exceptions are reported correctly to JVMTI in the compiled code >> 28: * @requires vm.jvmti > > You also require the JIT Added a requirement for the c1 or c2. > test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 32: > >> 30: * >> 31: * @build sun.hotspot.WhiteBox >> 32: * @build compiler.jvmti.TriggerBuiltinExceptionsTest > > Explicit build directive should not be needed. Fixed, thanks > test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 59: > >> 57: public class TriggerBuiltinExceptionsTest { >> 58: private static final WhiteBox WB = WhiteBox.getWhiteBox(); >> 59: private static final int ITERATIONS = 30; //Arbitrary value, feel free to change > > Style nit: space after // Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From enikitin at openjdk.java.net Thu Dec 16 20:20:53 2021 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Thu, 16 Dec 2021 20:20:53 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 22:32:34 GMT, Serguei Spitsyn wrote: >> Evgeny Nikitin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Get rid of while-breaks >> - Add JIT requirements >> - Remove explicit type specifiers for own class static calls >> - Remove redundant build directive >> - Merge branch 'master' into JDK-8274982/public >> - 8274982: Add a test for 8269574. > > test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 128: > >> 126: >> 127: Asserts.assertEQ( >> 128: TriggerBuiltinExceptionsTest.caughtByJVMTIAgent(), caughtByJavaTest, > > What is the reason to use the class name prefix for methods? : > TriggerBuiltinExceptionsTest.compileMethodOrThrow > TriggerBuiltinExceptionsTest.methodToCompile > TriggerBuiltinExceptionsTest.caughtByJVMTIAgent > It is not really needed, tight? Style habits, acquired in previons job... fixed. > test/hotspot/jtreg/compiler/jvmti/libTriggerBuiltinExceptions.cpp line 77: > >> 75: } >> 76: >> 77: } while (false); > > I'm not sure why the while (false) loop is needed. > You can always return JNI_ERR instead of break in all places where the > result != JVMTI_ERROR_NONE is detected and return JNI_OK at the end. > Is it to for one-return style? Remnants from a previous, draft version. Fixed (along with unnecessary 'successfull' variable removal). ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From lmesnik at openjdk.java.net Thu Dec 16 20:55:09 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 16 Dec 2021 20:55:09 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: <0_iROrhelCBAS2sNgY6vkvDjCq0sh_5skuY41Zi_Lhg=.a1f21483-cdc1-40cd-98c3-c93adbdacbdb@github.com> References: <0_iROrhelCBAS2sNgY6vkvDjCq0sh_5skuY41Zi_Lhg=.a1f21483-cdc1-40cd-98c3-c93adbdacbdb@github.com> Message-ID: On Thu, 16 Dec 2021 20:20:41 GMT, Evgeny Nikitin wrote: >> This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. > > Evgeny Nikitin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Get rid of while-breaks > - Add JIT requirements > - Remove explicit type specifiers for own class static calls > - Remove redundant build directive > - Merge branch 'master' into JDK-8274982/public > - 8274982: Add a test for 8269574. Marked as reviewed by lmesnik (Reviewer). test/hotspot/jtreg/compiler/jvmti/libTriggerBuiltinExceptions.cpp line 79: > 77: } while (false); > 78: > 79: return (result == JNI_OK) || (result == JVMTI_ERROR_NONE) ? JNI_OK : JNI_ERR; Seems (result == JNI_OK) || (result == JVMTI_ERROR_NONE) should be (result == JNI_OK) && (result == JVMTI_ERROR_NONE). Really, I think it would be better to replace do { ... break; .. } while (false) with multiply return. It makes logic simpler and style compliant to all jvmti tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From lmesnik at openjdk.java.net Thu Dec 16 20:55:09 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 16 Dec 2021 20:55:09 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 20:16:39 GMT, Evgeny Nikitin wrote: >> test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 28: >> >>> 26: * @bug 8269574 >>> 27: * @summary Verifies that exceptions are reported correctly to JVMTI in the compiled code >>> 28: * @requires vm.jvmti >> >> You also require the JIT > > Added a requirement for the c1 or c2. Really, we don't add @requires for jit compiler. There are a lot of tests that fail with Xnt. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From dholmes at openjdk.java.net Thu Dec 16 22:17:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 16 Dec 2021 22:17:09 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: <0_iROrhelCBAS2sNgY6vkvDjCq0sh_5skuY41Zi_Lhg=.a1f21483-cdc1-40cd-98c3-c93adbdacbdb@github.com> References: <0_iROrhelCBAS2sNgY6vkvDjCq0sh_5skuY41Zi_Lhg=.a1f21483-cdc1-40cd-98c3-c93adbdacbdb@github.com> Message-ID: On Thu, 16 Dec 2021 20:20:41 GMT, Evgeny Nikitin wrote: >> This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. > > Evgeny Nikitin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Get rid of while-breaks > - Add JIT requirements > - Remove explicit type specifiers for own class static calls > - Remove redundant build directive > - Merge branch 'master' into JDK-8274982/public > - 8274982: Add a test for 8269574. A few more comments below. Thanks, David test/hotspot/jtreg/compiler/jvmti/libTriggerBuiltinExceptions.cpp line 37: > 35: jmethodID catch_method, jlocation catch_location) { > 36: exceptions_caught += 1; > 37: } IIUC this will count all exceptions occurring in any thread and in relation to any method. There are behind-the-scenes exceptions that can occur which may cause this to count exceptions not related to the test. I think you need to only count those thrown in the method of interest, for reliability. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From dholmes at openjdk.java.net Thu Dec 16 22:17:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 16 Dec 2021 22:17:09 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 20:51:17 GMT, Leonid Mesnik wrote: >> Added a requirement for the c1 or c2. > > Really, we don't add @requires for jit compiler. There are a lot of tests that fail with Xnt. Tests outside of the compiler area which explicitly use features like ` WB.enqueueMethodForCompilation` which explicitly will fail if there is no JIT either require the JIT or exclude running with Zero. See for example: ./runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java ./runtime/Unsafe/InternalErrorTest.java ./runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java EDIT: except of course this test is in the compiler area . Okay perhaps overkill - sorry for the noise. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From cjplummer at openjdk.java.net Thu Dec 16 23:28:37 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 16 Dec 2021 23:28:37 GMT Subject: Integrated: 8276982: VM.class_hierarchy jcmd help output and man page text needs clarifications/improvements In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 03:08:40 GMT, Chris Plummer wrote: > Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page. This pull request has now been integrated. Changeset: 7ce4aa89 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/7ce4aa894279b76b6033bb4a1d0caa00d4213406 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod 8276982: VM.class_hierarchy jcmd help output and man page text needs clarifications/improvements Reviewed-by: stuefe, dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6845 From hedongbo at huawei.com Fri Dec 17 01:35:06 2021 From: hedongbo at huawei.com (hedongbo) Date: Fri, 17 Dec 2021 01:35:06 +0000 Subject: [8u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load Message-ID: <4dd54b5a943842868ec4b1c8aed2dbf3@huawei.com> Hi, Please review the backport of JDK-8173361 to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8173361 11u commit: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/99bdef096320 8u webrev: https://cr.openjdk.java.net/~dongbohe/8173361/webrev.00/ This patch doesn't apply cleanly. I turned NoSafepointVerifier to No_Safepoint_Verifier because JDK- 8146690[1] changed the naming convention. I removed the mutexLocker.cpp changeset because JDK-8047290[2] does not exist in 8. I added the CLDClosure* to ServiceThread::oops_do because JDK- 8154580[3] does not exist in 8. Tested with tier1. No regression in tests. Follow-up fix JDK-8235218[4] is planned to be backported as well. [1] https://bugs.openjdk.java.net/browse/JDK-8146690 [2] https://bugs.openjdk.java.net/browse/JDK-8047290 [3] https://bugs.openjdk.java.net/browse/JDK-8154580 [4] https://bugs.openjdk.java.net/browse/JDK-8235218 Thanks, hedongbo -------------- next part -------------- An HTML attachment was scrubbed... URL: From amenkov at openjdk.java.net Fri Dec 17 01:54:44 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 17 Dec 2021 01:54:44 GMT Subject: RFR: 8278519: serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java failed "assert(handle != __null) failed: JNI handle should not be null" Message-ID: The fix adds a check in the event handler which filters out event from non-test threads ------------- Commit messages: - Filter out events from other threads Changes: https://git.openjdk.java.net/jdk/pull/6874/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6874&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278519 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6874/head:pull/6874 PR: https://git.openjdk.java.net/jdk/pull/6874 From dholmes at openjdk.java.net Fri Dec 17 02:26:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 17 Dec 2021 02:26:25 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 17:33:29 GMT, Harold Seigel wrote: > Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. > > Thanks! Harold Hi Harold, Change looks good and I've Reviewed the CSR request. One nit in the test. Thanks, David test/hotspot/jtreg/runtime/BootClassAppendProp/GetBootClassPathAppendProp.java line 40: > 38: > 39: public static void main(String[] args) throws Exception { > 40: String vm_info_jvmti = getSystemProperty(); Nit: strange name and doesn't follow Java style rules. Won't "path" suffice? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6868 From sspitsyn at openjdk.java.net Fri Dec 17 03:21:32 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 17 Dec 2021 03:21:32 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string In-Reply-To: References: Message-ID: <3kIIfQj2ARKIReNLCxZHDypdwn5V25xrfuzSBhB8QWo=.64e91214-5a8e-4e47-a784-3413b7098f27@github.com> On Thu, 16 Dec 2021 17:33:29 GMT, Harold Seigel wrote: > Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. > > Thanks! Harold Hi Harold, The fix looks good to me. Thanks, Serguei test/hotspot/jtreg/runtime/BootClassAppendProp/GetBootClassPathAppendProp.java line 26: > 24: /** > 25: * @test > 26: * @bug 8224791 The 8224791 has been closed. Should it be replaced with 8225093? ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6868 From sspitsyn at openjdk.java.net Fri Dec 17 03:26:32 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 17 Dec 2021 03:26:32 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: <0_iROrhelCBAS2sNgY6vkvDjCq0sh_5skuY41Zi_Lhg=.a1f21483-cdc1-40cd-98c3-c93adbdacbdb@github.com> References: <0_iROrhelCBAS2sNgY6vkvDjCq0sh_5skuY41Zi_Lhg=.a1f21483-cdc1-40cd-98c3-c93adbdacbdb@github.com> Message-ID: On Thu, 16 Dec 2021 20:20:41 GMT, Evgeny Nikitin wrote: >> This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. > > Evgeny Nikitin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Get rid of while-breaks > - Add JIT requirements > - Remove explicit type specifiers for own class static calls > - Remove redundant build directive > - Merge branch 'master' into JDK-8274982/public > - 8274982: Add a test for 8269574. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From cjplummer at openjdk.java.net Fri Dec 17 03:34:23 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 17 Dec 2021 03:34:23 GMT Subject: RFR: 8278519: serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java failed "assert(handle != __null) failed: JNI handle should not be null" In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 01:47:23 GMT, Alex Menkov wrote: > The fix adds a check in the event handler which filters out event from non-test threads You need to update the copyright in libFieldAccessWatch.c. Otherwise the changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6874 From sspitsyn at openjdk.java.net Fri Dec 17 08:48:29 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 17 Dec 2021 08:48:29 GMT Subject: RFR: 8278519: serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java failed "assert(handle != __null) failed: JNI handle should not be null" In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 01:47:23 GMT, Alex Menkov wrote: > The fix adds a check in the event handler which filters out event from non-test threads Looks good. Chris already pointed to the Copyright year. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6874 From enikitin at openjdk.java.net Fri Dec 17 13:07:19 2021 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Fri, 17 Dec 2021 13:07:19 GMT Subject: RFR: 8274982: Add a test for 8269574. [v2] In-Reply-To: References: Message-ID: <6ChWczwTF_sDpFJ3oGDKt_nMNuX2d638hG0kMimhkWM=.8626f9e6-34aa-4518-8358-8557c0e83798@github.com> On Wed, 10 Nov 2021 20:49:54 GMT, Vladimir Kozlov wrote: > What testing was done? What testing tiers were run? I've run with intentionally broken prod. code (the 8269574 unfixed) - the test catches the problem. Additionally, I've run the test and tiers 1-2-3. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From hseigel at openjdk.java.net Fri Dec 17 13:44:01 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 17 Dec 2021 13:44:01 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v2] In-Reply-To: References: Message-ID: > Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. > > Thanks! Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: fix test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6868/files - new: https://git.openjdk.java.net/jdk/pull/6868/files/bd80b91b..a1c9218b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6868/head:pull/6868 PR: https://git.openjdk.java.net/jdk/pull/6868 From hseigel at openjdk.java.net Fri Dec 17 13:44:03 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 17 Dec 2021 13:44:03 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 17:33:29 GMT, Harold Seigel wrote: > Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. > > Thanks! Harold Thanks David and Serguei for reviewing this, and thanks David for reviewing the CSR. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From hseigel at openjdk.java.net Fri Dec 17 13:44:06 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 17 Dec 2021 13:44:06 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v2] In-Reply-To: <3kIIfQj2ARKIReNLCxZHDypdwn5V25xrfuzSBhB8QWo=.64e91214-5a8e-4e47-a784-3413b7098f27@github.com> References: <3kIIfQj2ARKIReNLCxZHDypdwn5V25xrfuzSBhB8QWo=.64e91214-5a8e-4e47-a784-3413b7098f27@github.com> Message-ID: On Fri, 17 Dec 2021 03:17:23 GMT, Serguei Spitsyn wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test > > test/hotspot/jtreg/runtime/BootClassAppendProp/GetBootClassPathAppendProp.java line 26: > >> 24: /** >> 25: * @test >> 26: * @bug 8224791 > > The 8224791 has been closed. Should it be replaced with 8225093? Yes! Thanks for pointing that out. ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From hseigel at openjdk.java.net Fri Dec 17 13:44:08 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 17 Dec 2021 13:44:08 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v2] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 02:18:55 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test > > test/hotspot/jtreg/runtime/BootClassAppendProp/GetBootClassPathAppendProp.java line 40: > >> 38: >> 39: public static void main(String[] args) throws Exception { >> 40: String vm_info_jvmti = getSystemProperty(); > > Nit: strange name and doesn't follow Java style rules. Won't "path" suffice? The strange name comes from the test that I copied to write this one. I'll change it to 'path'. ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From amenkov at openjdk.java.net Fri Dec 17 20:03:03 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 17 Dec 2021 20:03:03 GMT Subject: RFR: 8278519: serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java failed "assert(handle != __null) failed: JNI handle should not be null" [v2] In-Reply-To: References: Message-ID: > The fix adds a check in the event handler which filters out event from non-test threads Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Updated copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6874/files - new: https://git.openjdk.java.net/jdk/pull/6874/files/022a689f..35a6a35a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6874&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6874&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6874/head:pull/6874 PR: https://git.openjdk.java.net/jdk/pull/6874 From dholmes at openjdk.java.net Sat Dec 18 00:47:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 18 Dec 2021 00:47:28 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v2] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 13:44:01 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. >> >> Thanks! Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix test Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From cjplummer at openjdk.java.net Sat Dec 18 01:25:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sat, 18 Dec 2021 01:25:47 GMT Subject: RFR: 8244670: convert clhsdb "whatis" command from javascript to java Message-ID: "whatis" is one of the old clhsdb commands that was written in javascript and lost when Nashorn support was removed. The old "whatis" is the same as the old "findpc", but also called LoadObject.lookup() on the address and also tried to determine the C++ Type of the address. However, with the improvements made to PointerFinder by JDK-8247514, findpc now also includes support for this (plus other types of address lookups), so these two commands will do the same thing. I'm still adding "whatis" since some people might still rely on it from when it worked in JDK 8, and may not know that findpc will do the same. ------------- Commit messages: - Add clhsdb whatis command Changes: https://git.openjdk.java.net/jdk/pull/6887/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6887&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244670 Stats: 21 lines in 2 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6887.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6887/head:pull/6887 PR: https://git.openjdk.java.net/jdk/pull/6887 From amenkov at openjdk.java.net Sat Dec 18 08:12:22 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Sat, 18 Dec 2021 08:12:22 GMT Subject: Integrated: 8278519: serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java failed "assert(handle != __null) failed: JNI handle should not be null" In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 01:47:23 GMT, Alex Menkov wrote: > The fix adds a check in the event handler which filters out event from non-test threads This pull request has now been integrated. Changeset: 63e43030 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/63e43030ed1260d14df950342c39a377231a3f40 Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 mod 8278519: serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java failed "assert(handle != __null) failed: JNI handle should not be null" Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6874 From sspitsyn at openjdk.java.net Mon Dec 20 09:47:25 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 20 Dec 2021 09:47:25 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v2] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 13:44:01 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. >> >> Thanks! Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix test Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From sspitsyn at openjdk.java.net Mon Dec 20 09:52:26 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 20 Dec 2021 09:52:26 GMT Subject: RFR: 8244670: convert clhsdb "whatis" command from javascript to java In-Reply-To: References: Message-ID: On Sat, 18 Dec 2021 01:08:04 GMT, Chris Plummer wrote: > "whatis" is one of the old clhsdb commands that was written in javascript and lost when Nashorn support was removed. The old "whatis" is the same as the old "findpc", but also called LoadObject.lookup() on the address and also tried to determine the C++ Type of the address. However, with the improvements made to PointerFinder by JDK-8247514, findpc now also includes support for this (plus other types of address lookups), so these two commands will do the same thing. I'm still adding "whatis" since some people might still rely on it from when it worked in JDK 8, and may not know that findpc will do the same. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6887 From alanb at openjdk.java.net Mon Dec 20 17:37:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 20 Dec 2021 17:37:22 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v2] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 13:44:01 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. >> >> Thanks! Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix test Marked as reviewed by alanb (Reviewer). test/hotspot/jtreg/runtime/BootClassAppendProp/libGetBootClassPathAppendProp.c line 53: > 51: if (err != JVMTI_ERROR_NONE) { > 52: return (*env)->NewStringUTF(env, "wrong error code"); > 53: } For diagnosability it may be helpful to have this native method throw an exception with the JVMTI error code or alternatively have the return String include the error code rather than a generic message "wrong error code". ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From cjplummer at openjdk.java.net Mon Dec 20 17:43:50 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 20 Dec 2021 17:43:50 GMT Subject: RFR: 8244670: convert clhsdb "whatis" command from javascript to java [v2] In-Reply-To: References: Message-ID: > "whatis" is one of the old clhsdb commands that was written in javascript and lost when Nashorn support was removed. The old "whatis" is the same as the old "findpc", but also called LoadObject.lookup() on the address and also tried to determine the C++ Type of the address. However, with the improvements made to PointerFinder by JDK-8247514, findpc now also includes support for this (plus other types of address lookups), so these two commands will do the same thing. I'm still adding "whatis" since some people might still rely on it from when it worked in JDK 8, and may not know that findpc will do the same. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Update help for whatis command ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6887/files - new: https://git.openjdk.java.net/jdk/pull/6887/files/859a35f6..d23db30b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6887&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6887&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6887.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6887/head:pull/6887 PR: https://git.openjdk.java.net/jdk/pull/6887 From cjplummer at openjdk.java.net Mon Dec 20 17:46:45 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 20 Dec 2021 17:46:45 GMT Subject: RFR: 8244670: convert clhsdb "whatis" command from javascript to java [v3] In-Reply-To: References: Message-ID: <9mwwNZ2lMcXLJfeHvz5v_Jbq-KcUEEIWU09-pKy_udc=.5badebdf-a21f-4455-aa68-742640e74a29@github.com> > "whatis" is one of the old clhsdb commands that was written in javascript and lost when Nashorn support was removed. The old "whatis" is the same as the old "findpc", but also called LoadObject.lookup() on the address and also tried to determine the C++ Type of the address. However, with the improvements made to PointerFinder by JDK-8247514, findpc now also includes support for this (plus other types of address lookups), so these two commands will do the same thing. I'm still adding "whatis" since some people might still rely on it from when it worked in JDK 8, and may not know that findpc will do the same. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6887/files - new: https://git.openjdk.java.net/jdk/pull/6887/files/d23db30b..b158e66a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6887&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6887&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6887.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6887/head:pull/6887 PR: https://git.openjdk.java.net/jdk/pull/6887 From hseigel at openjdk.java.net Mon Dec 20 18:36:45 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 20 Dec 2021 18:36:45 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v3] In-Reply-To: References: Message-ID: > Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. > > Thanks! Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: Add error code to test failure message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6868/files - new: https://git.openjdk.java.net/jdk/pull/6868/files/a1c9218b..97d60c7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6868/head:pull/6868 PR: https://git.openjdk.java.net/jdk/pull/6868 From hseigel at openjdk.java.net Mon Dec 20 18:36:49 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 20 Dec 2021 18:36:49 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v2] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 17:33:58 GMT, Alan Bateman wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test > > test/hotspot/jtreg/runtime/BootClassAppendProp/libGetBootClassPathAppendProp.c line 53: > >> 51: if (err != JVMTI_ERROR_NONE) { >> 52: return (*env)->NewStringUTF(env, "wrong error code"); >> 53: } > > For diagnosability it may be helpful to have this native method throw an exception with the JVMTI error code or alternatively have the return String include the error code rather than a generic message "wrong error code". Thanks Alan! I updated the test to include the JVM TI error code in the above 'wrong error code' message. ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From alanb at openjdk.java.net Mon Dec 20 18:49:31 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 20 Dec 2021 18:49:31 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v3] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 18:36:45 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. >> >> Thanks! Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Add error code to test failure message Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From dholmes at openjdk.java.net Mon Dec 20 22:36:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 20 Dec 2021 22:36:33 GMT Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not default to empty string [v3] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 18:36:45 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "". This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. The fix was also tested by running the agent.c example in JDK-8224791. >> >> Thanks! Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Add error code to test failure message Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6868 From cjplummer at openjdk.java.net Tue Dec 21 01:32:39 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 01:32:39 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java Message-ID: clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. ------------- Commit messages: - Add support for clhsdb 'mem' command. Changes: https://git.openjdk.java.net/jdk/pull/6902/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6902&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244669 Stats: 158 lines in 3 files changed: 121 ins; 29 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6902/head:pull/6902 PR: https://git.openjdk.java.net/jdk/pull/6902 From cjplummer at openjdk.java.net Tue Dec 21 02:25:31 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 02:25:31 GMT Subject: RFR: 8279024: Remove javascript references from clhsdb.html Message-ID: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> clhsdb no longer supports javascript. Remove some remaining references in the docs. I also removed some script references. ------------- Commit messages: - minor fix to doc - Remove javascript references Changes: https://git.openjdk.java.net/jdk/pull/6903/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6903&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279024 Stats: 52 lines in 2 files changed: 1 ins; 49 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6903.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6903/head:pull/6903 PR: https://git.openjdk.java.net/jdk/pull/6903 From dholmes at openjdk.java.net Tue Dec 21 02:38:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 21 Dec 2021 02:38:20 GMT Subject: RFR: 8279024: Remove javascript references from clhsdb.html In-Reply-To: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> References: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> Message-ID: On Tue, 21 Dec 2021 02:17:10 GMT, Chris Plummer wrote: > clhsdb no longer supports javascript. Remove some remaining references in the docs. I also removed some script references. This should be fixed in 18. ------------- PR: https://git.openjdk.java.net/jdk/pull/6903 From cjplummer at openjdk.java.net Tue Dec 21 03:47:12 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 03:47:12 GMT Subject: RFR: 8279024: Remove javascript references from clhsdb.html In-Reply-To: References: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> Message-ID: On Tue, 21 Dec 2021 02:34:38 GMT, David Holmes wrote: > This should be fixed in 18. SA Javascript support broke in JDK 9. It was removed in JDK 15. See [JDK-8244668](https://bugs.openjdk.java.net/browse/JDK-8244668). Yes, this could go into 18, but since I'm not currently setup for 18 I'd rather just push to 19. At this point it doesn't seem important enough for the extra work to get it into 18. ------------- PR: https://git.openjdk.java.net/jdk/pull/6903 From cjplummer at openjdk.java.net Tue Dec 21 07:17:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 07:17:47 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v2] In-Reply-To: References: Message-ID: > clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. > > Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. > > The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Change output string we look for so it passes on all platforms. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6902/files - new: https://git.openjdk.java.net/jdk/pull/6902/files/5fd9e19c..15a447bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6902&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6902&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6902/head:pull/6902 PR: https://git.openjdk.java.net/jdk/pull/6902 From kevinw at openjdk.java.net Tue Dec 21 09:51:21 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 21 Dec 2021 09:51:21 GMT Subject: RFR: 8244670: convert clhsdb "whatis" command from javascript to java [v3] In-Reply-To: <9mwwNZ2lMcXLJfeHvz5v_Jbq-KcUEEIWU09-pKy_udc=.5badebdf-a21f-4455-aa68-742640e74a29@github.com> References: <9mwwNZ2lMcXLJfeHvz5v_Jbq-KcUEEIWU09-pKy_udc=.5badebdf-a21f-4455-aa68-742640e74a29@github.com> Message-ID: On Mon, 20 Dec 2021 17:46:45 GMT, Chris Plummer wrote: >> "whatis" is one of the old clhsdb commands that was written in javascript and lost when Nashorn support was removed. The old "whatis" is the same as the old "findpc", but also called LoadObject.lookup() on the address and also tried to determine the C++ Type of the address. However, with the improvements made to PointerFinder by JDK-8247514, findpc now also includes support for this (plus other types of address lookups), so these two commands will do the same thing. I'm still adding "whatis" since some people might still rely on it from when it worked in JDK 8, and may not know that findpc will do the same. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6887 From kevinw at openjdk.java.net Tue Dec 21 09:52:16 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 21 Dec 2021 09:52:16 GMT Subject: RFR: 8279024: Remove javascript references from clhsdb.html In-Reply-To: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> References: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> Message-ID: <_kahRZN4iVjJcnsBZ-Z5Uc321ncMGJFLAYbkOpgMT1U=.94957397-719a-4a52-8fb2-c0fc16e4063a@github.com> On Tue, 21 Dec 2021 02:17:10 GMT, Chris Plummer wrote: > clhsdb no longer supports javascript. Remove some remaining references in the docs. I also removed some script references. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6903 From sspitsyn at openjdk.java.net Tue Dec 21 09:58:11 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 21 Dec 2021 09:58:11 GMT Subject: RFR: 8279024: Remove javascript references from clhsdb.html In-Reply-To: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> References: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> Message-ID: On Tue, 21 Dec 2021 02:17:10 GMT, Chris Plummer wrote: > clhsdb no longer supports javascript. Remove some remaining references in the docs. I also removed some script references. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6903 From kevinw at openjdk.java.net Tue Dec 21 13:06:46 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 21 Dec 2021 13:06:46 GMT Subject: [jdk18] RFR: 8279007: jstatd fails to start because SecurityManager is disabled Message-ID: jstatd now in jdk18 fails to start unless we specifically allow or set a SecurityManager. This update to the launcher makefile adds JAVA_ARGS to permit a SecurityManager. ------------- Commit messages: - 8279007: jstatd fails to start because SecurityManager is disabled Changes: https://git.openjdk.java.net/jdk18/pull/53/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=53&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279007 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk18/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk18/pull/53 From alanb at openjdk.java.net Tue Dec 21 13:13:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 21 Dec 2021 13:13:21 GMT Subject: [jdk18] RFR: 8279007: jstatd fails to start because SecurityManager is disabled In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 13:00:26 GMT, Kevin Walls wrote: > jstatd now in jdk18 fails to start unless we specifically allow or set a SecurityManager. > This update to the launcher makefile adds JAVA_ARGS to permit a SecurityManager. This looks okay in that it is now worked exactly as it did in JDK 17. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/53 From mullan at openjdk.java.net Tue Dec 21 15:15:24 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 21 Dec 2021 15:15:24 GMT Subject: [jdk18] RFR: 8279007: jstatd fails to start because SecurityManager is disabled In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 13:00:26 GMT, Kevin Walls wrote: > jstatd now in jdk18 fails to start unless we specifically allow or set a SecurityManager. > This update to the launcher makefile adds JAVA_ARGS to permit a SecurityManager. You should also remove `-Djava.security.manager=allow` from the jstatd test (`test/jdk/sun/tools/jstatd/JstatdTest.java`) as it is not needed now. ------------- PR: https://git.openjdk.java.net/jdk18/pull/53 From cjplummer at openjdk.java.net Tue Dec 21 19:58:53 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 19:58:53 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v3] In-Reply-To: References: Message-ID: > clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. > > Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. > > The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: - Fix issue with address range patterns. For some reason they have always allowed some extra lower case letters at the end of the pattern that just get ignored. I removed support for this since sometimes it resulted in bad address ranges producing an exception rather than a usage() message. - Fix missing return after calling usage() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6902/files - new: https://git.openjdk.java.net/jdk/pull/6902/files/15a447bf..dad80346 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6902&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6902&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6902/head:pull/6902 PR: https://git.openjdk.java.net/jdk/pull/6902 From dcubed at openjdk.java.net Tue Dec 21 20:05:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 21 Dec 2021 20:05:42 GMT Subject: [jdk18] RFR: 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms Message-ID: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms ------------- Commit messages: - 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms Changes: https://git.openjdk.java.net/jdk18/pull/61/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=61&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279081 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk18/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk18/pull/61 From kevinw at openjdk.java.net Tue Dec 21 20:28:52 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 21 Dec 2021 20:28:52 GMT Subject: [jdk18] RFR: 8279007: jstatd fails to start because SecurityManager is disabled [v2] In-Reply-To: References: Message-ID: > jstatd now in jdk18 fails to start unless we specifically allow or set a SecurityManager. > This update to the launcher makefile adds JAVA_ARGS to permit a SecurityManager. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove security manager property from jstatd tests. ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/53/files - new: https://git.openjdk.java.net/jdk18/pull/53/files/eaf7ddf6..27d4f689 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=53&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=53&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk18/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk18/pull/53 From kevinw at openjdk.java.net Tue Dec 21 20:28:53 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 21 Dec 2021 20:28:53 GMT Subject: [jdk18] RFR: 8279007: jstatd fails to start because SecurityManager is disabled In-Reply-To: References: Message-ID: <1qFEEtPbMYYVVTaAo-ROPQ4CTtHHviz1H048Szx8A9Q=.ea67192e-703d-4035-9063-41bb28b22fb3@github.com> On Tue, 21 Dec 2021 15:12:19 GMT, Sean Mullan wrote: > You should also remove `-Djava.security.manager=allow` from the jstatd test (`test/jdk/sun/tools/jstatd/JstatdTest.java`) as it is not needed now. Yes of course! Thanks. ------------- PR: https://git.openjdk.java.net/jdk18/pull/53 From azvegint at openjdk.java.net Tue Dec 21 20:42:18 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 21 Dec 2021 20:42:18 GMT Subject: [jdk18] RFR: 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms In-Reply-To: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com> References: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com> Message-ID: On Tue, 21 Dec 2021 19:56:07 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/61 From sspitsyn at openjdk.java.net Tue Dec 21 20:42:18 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 21 Dec 2021 20:42:18 GMT Subject: [jdk18] RFR: 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms In-Reply-To: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com> References: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com> Message-ID: On Tue, 21 Dec 2021 19:56:07 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms Hi Dan, This is good and trivial. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/61 From dcubed at openjdk.java.net Tue Dec 21 20:42:18 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 21 Dec 2021 20:42:18 GMT Subject: [jdk18] RFR: 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms In-Reply-To: References: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com> Message-ID: On Tue, 21 Dec 2021 20:36:05 GMT, Alexander Zvegintsev wrote: >> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms > > Marked as reviewed by azvegint (Reviewer). @azvegint and @sspitsyn - Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk18/pull/61 From dcubed at openjdk.java.net Tue Dec 21 20:42:18 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 21 Dec 2021 20:42:18 GMT Subject: [jdk18] Integrated: 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms In-Reply-To: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com> References: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com> Message-ID: On Tue, 21 Dec 2021 19:56:07 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms This pull request has now been integrated. Changeset: 84d3333c Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk18/commit/84d3333c7a979742021e759766a7290539b569f4 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms Reviewed-by: azvegint, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk18/pull/61 From sspitsyn at openjdk.java.net Tue Dec 21 20:43:32 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 21 Dec 2021 20:43:32 GMT Subject: [jdk18] RFR: 8279007: jstatd fails to start because SecurityManager is disabled [v2] In-Reply-To: References: Message-ID: <7kyFuSAYDORMCeH4PykfD_Onwp69jBkrFrvozqBCGzs=.cb5abbc2-89a0-4ec8-b0df-6b3663bad0dc@github.com> On Tue, 21 Dec 2021 20:28:52 GMT, Kevin Walls wrote: >> jstatd now in jdk18 fails to start unless we specifically allow or set a SecurityManager. >> This update to the launcher makefile adds JAVA_ARGS to permit a SecurityManager. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove security manager property from jstatd tests. Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/53 From mullan at openjdk.java.net Tue Dec 21 21:05:15 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 21 Dec 2021 21:05:15 GMT Subject: [jdk18] RFR: 8279007: jstatd fails to start because SecurityManager is disabled [v2] In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 20:28:52 GMT, Kevin Walls wrote: >> jstatd now in jdk18 fails to start unless we specifically allow or set a SecurityManager. >> This update to the launcher makefile adds JAVA_ARGS to permit a SecurityManager. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove security manager property from jstatd tests. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/53 From kvn at openjdk.java.net Tue Dec 21 21:17:16 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 21 Dec 2021 21:17:16 GMT Subject: [jdk18] RFR: 8278239: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine failed with EXCEPTION_ACCESS_VIOLATION at 0x000000000000000d In-Reply-To: References: Message-ID: <-5p48Ttu4Th7IdX7X2HqEdQYm1iFRxkyXQFB4Hnswvw=.ae121f39-801c-4d03-8759-739ccf3e5b10@github.com> On Tue, 21 Dec 2021 20:51:04 GMT, Coleen Phillimore wrote: > This is the fix for https://github.com/openjdk/jdk/pull/6900 retargeted to JDK 18. > > Thanks to @stefank and @fisk for the diagnosis. ZGC is looking at metadata in unloaded nmethods, but redefinition doesn't keep this metadata from being deallocated. Change the iterators that mark metadata in use to walk unloaded nmethods as well as other alive nmethods. > > The test case reproduces the crash on windows if run in an 100 iteration loop. This fix does not crash in the same test. Also ran tier1-6. > > Above testing in progress. okay ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/63 From sspitsyn at openjdk.java.net Tue Dec 21 21:26:21 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 21 Dec 2021 21:26:21 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v3] In-Reply-To: References: Message-ID: <1iS-osjAGvMSIo2-77_2eof8Je5lNOY_zaNDMNu1GZs=.40cdcb18-56e8-497e-a6cb-7d51a34d480c@github.com> On Tue, 21 Dec 2021 19:58:53 GMT, Chris Plummer wrote: >> clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. >> >> Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. >> >> The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. > > Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: > > - Fix issue with address range patterns. For some reason they have always allowed some extra lower case letters at the end of the pattern that just get ignored. I removed support for this since sometimes it resulted in bad address ranges producing an exception rather than a usage() message. > - Fix missing return after calling usage() src/jdk.hotspot.agent/doc/clhsdb.html line 54: > 52: dumpreplaydata <address> | -a | <thread_id> [>replay.txt] dump replay data into a file > 53: echo [ true | false ] turn on/off command echo mode > 54: examine { address[/count] | address,address } show contents of memory from given address It would cover both input variants if to say: "show contents of memory range" src/jdk.hotspot.agent/doc/clhsdb.html line 70: > 68: livenmethods show all live nmethods > 69: longConstant [ name [ value ] ] print out hotspot long constant(s)s > 70: mem [ -v ] { address[/count] | address,address } show contents of memory. optionally include "findpc" info for addresses The same as above. ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From sspitsyn at openjdk.java.net Tue Dec 21 21:32:19 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 21 Dec 2021 21:32:19 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v3] In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 19:58:53 GMT, Chris Plummer wrote: >> clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. >> >> Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. >> >> The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. > > Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: > > - Fix issue with address range patterns. For some reason they have always allowed some extra lower case letters at the end of the pattern that just get ignored. I removed support for this since sometimes it resulted in bad address ranges producing an exception rather than a usage() message. > - Fix missing return after calling usage() src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 560: > 558: } else { > 559: out.println(); > 560: } I wonder if it is possible to simplify the above fragment at 549-560 with something like: if (verbose) { // If we know what this is a pointer to, then print additional information. PointerLocation loc = PointerFinder.find(val); if (!loc.isUnknown()) { out.print(" "); loc.printOn(out, false, false); // make it print without line end or ignore there is an extra end? } } out.println(); test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java line 197: > 195: "In interpreter codelet: method entry point")); > 196: runTest(withCore, cmds, expStrMap); > 197: Is there a test case for another variant of range: Address,Address ? ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From cjplummer at openjdk.java.net Tue Dec 21 22:58:15 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 22:58:15 GMT Subject: Integrated: 8244670: convert clhsdb "whatis" command from javascript to java In-Reply-To: References: Message-ID: On Sat, 18 Dec 2021 01:08:04 GMT, Chris Plummer wrote: > "whatis" is one of the old clhsdb commands that was written in javascript and lost when Nashorn support was removed. The old "whatis" is the same as the old "findpc", but also called LoadObject.lookup() on the address and also tried to determine the C++ Type of the address. However, with the improvements made to PointerFinder by JDK-8247514, findpc now also includes support for this (plus other types of address lookups), so these two commands will do the same thing. I'm still adding "whatis" since some people might still rely on it from when it worked in JDK 8, and may not know that findpc will do the same. This pull request has now been integrated. Changeset: 00c0d108 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/00c0d1087021603f3f09131cb0458ac8b9c110e5 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod 8244670: convert clhsdb "whatis" command from javascript to java Reviewed-by: sspitsyn, kevinw ------------- PR: https://git.openjdk.java.net/jdk/pull/6887 From sspitsyn at openjdk.java.net Tue Dec 21 23:02:19 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 21 Dec 2021 23:02:19 GMT Subject: [jdk18] RFR: 8278239: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine failed with EXCEPTION_ACCESS_VIOLATION at 0x000000000000000d In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 20:51:04 GMT, Coleen Phillimore wrote: > This is the fix for https://github.com/openjdk/jdk/pull/6900 retargeted to JDK 18. > > Thanks to @stefank and @fisk for the diagnosis. ZGC is looking at metadata in unloaded nmethods, but redefinition doesn't keep this metadata from being deallocated. Change the iterators that mark metadata in use to walk unloaded nmethods as well as other alive nmethods. > > The test case reproduces the crash on windows if run in an 100 iteration loop. This fix does not crash in the same test. Also ran tier1-6. > > Above testing in progress. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/63 From cjplummer at openjdk.java.net Tue Dec 21 23:04:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 23:04:13 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v3] In-Reply-To: References: Message-ID: <3Cn3OnwVSp5AwISCdjFqynnZBSJfyWYMY1QGfVTEANE=.317eea24-6757-4a02-8be0-da97cfdcb26c@github.com> On Tue, 21 Dec 2021 21:27:24 GMT, Serguei Spitsyn wrote: >> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix issue with address range patterns. For some reason they have always allowed some extra lower case letters at the end of the pattern that just get ignored. I removed support for this since sometimes it resulted in bad address ranges producing an exception rather than a usage() message. >> - Fix missing return after calling usage() > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 560: > >> 558: } else { >> 559: out.println(); >> 560: } > > I wonder if it is possible to simplify the above fragment at 549-560 with something like: > if (verbose) { > // If we know what this is a pointer to, then print additional information. > PointerLocation loc = PointerFinder.find(val); > if (!loc.isUnknown()) { > out.print(" "); > loc.printOn(out, false, false); // make it print without line end or ignore there is an extra end? > } > } > out.println(); `printOn()` always prints a newline. It's hard to make it not do that since it relies on other `print` APIs, some of which print newlines and some of which don't (in which case `printOn()` will print a newline). So I can't easily just create a `printOn()` variant that doesn't print newlines, and printing two newlines would introduce a bunch of blank lines in the output, which wouldn't look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From cjplummer at openjdk.java.net Tue Dec 21 23:12:45 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 23:12:45 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v4] In-Reply-To: References: Message-ID: <-PIvfe2jyq9DlohUCI840LBflgwxpYwUr83PST0dq30=.fd1320f5-8dfc-4aec-8ff2-560ecfa7644b@github.com> > clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. > > Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. > > The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Minor improvements to help text for mem and examine. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6902/files - new: https://git.openjdk.java.net/jdk/pull/6902/files/dad80346..ed4ce4d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6902&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6902&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6902/head:pull/6902 PR: https://git.openjdk.java.net/jdk/pull/6902 From cjplummer at openjdk.java.net Tue Dec 21 23:12:52 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 23:12:52 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v3] In-Reply-To: <1iS-osjAGvMSIo2-77_2eof8Je5lNOY_zaNDMNu1GZs=.40cdcb18-56e8-497e-a6cb-7d51a34d480c@github.com> References: <1iS-osjAGvMSIo2-77_2eof8Je5lNOY_zaNDMNu1GZs=.40cdcb18-56e8-497e-a6cb-7d51a34d480c@github.com> Message-ID: On Tue, 21 Dec 2021 21:23:09 GMT, Serguei Spitsyn wrote: >> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix issue with address range patterns. For some reason they have always allowed some extra lower case letters at the end of the pattern that just get ignored. I removed support for this since sometimes it resulted in bad address ranges producing an exception rather than a usage() message. >> - Fix missing return after calling usage() > > src/jdk.hotspot.agent/doc/clhsdb.html line 54: > >> 52: dumpreplaydata <address> | -a | <thread_id> [>replay.txt] dump replay data into a file >> 53: echo [ true | false ] turn on/off command echo mode >> 54: examine { address[/count] | address,address } show contents of memory from given address > > It would cover both input variants if to say: > "show contents of memory range" Ok. Change has been made. > src/jdk.hotspot.agent/doc/clhsdb.html line 70: > >> 68: livenmethods show all live nmethods >> 69: longConstant [ name [ value ] ] print out hotspot long constant(s)s >> 70: mem [ -v ] { address[/count] | address,address } show contents of memory. optionally include "findpc" info for addresses > > The same as above. Ok. Change has been made. ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From sspitsyn at openjdk.java.net Tue Dec 21 23:33:16 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 21 Dec 2021 23:33:16 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v3] In-Reply-To: <3Cn3OnwVSp5AwISCdjFqynnZBSJfyWYMY1QGfVTEANE=.317eea24-6757-4a02-8be0-da97cfdcb26c@github.com> References: <3Cn3OnwVSp5AwISCdjFqynnZBSJfyWYMY1QGfVTEANE=.317eea24-6757-4a02-8be0-da97cfdcb26c@github.com> Message-ID: On Tue, 21 Dec 2021 23:01:20 GMT, Chris Plummer wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 560: >> >>> 558: } else { >>> 559: out.println(); >>> 560: } >> >> I wonder if it is possible to simplify the above fragment at 549-560 with something like: >> if (verbose) { >> // If we know what this is a pointer to, then print additional information. >> PointerLocation loc = PointerFinder.find(val); >> if (!loc.isUnknown()) { >> out.print(" "); >> loc.printOn(out, false, false); // make it print without line end or ignore there is an extra end? >> } >> } >> out.println(); > > `printOn()` always prints a newline. It's hard to make it not do that since it relies on other `print` APIs, some of which print newlines and some of which don't (in which case `printOn()` will print a newline). So I can't easily just create a `printOn()` variant that doesn't print newlines, and printing two newlines would introduce a bunch of blank lines in the output, which wouldn't look good. Okay, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From sspitsyn at openjdk.java.net Tue Dec 21 23:33:15 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 21 Dec 2021 23:33:15 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v4] In-Reply-To: <-PIvfe2jyq9DlohUCI840LBflgwxpYwUr83PST0dq30=.fd1320f5-8dfc-4aec-8ff2-560ecfa7644b@github.com> References: <-PIvfe2jyq9DlohUCI840LBflgwxpYwUr83PST0dq30=.fd1320f5-8dfc-4aec-8ff2-560ecfa7644b@github.com> Message-ID: On Tue, 21 Dec 2021 23:12:45 GMT, Chris Plummer wrote: >> clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. >> >> Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. >> >> The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor improvements to help text for mem and examine. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From cjplummer at openjdk.java.net Tue Dec 21 23:50:16 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 21 Dec 2021 23:50:16 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v3] In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 21:28:43 GMT, Serguei Spitsyn wrote: >> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix issue with address range patterns. For some reason they have always allowed some extra lower case letters at the end of the pattern that just get ignored. I removed support for this since sometimes it resulted in bad address ranges producing an exception rather than a usage() message. >> - Fix missing return after calling usage() > > test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java line 197: > >> 195: "In interpreter codelet: method entry point")); >> 196: runTest(withCore, cmds, expStrMap); >> 197: > > Is there a test case for another variant of range: Address,Address ? No. We really never had any specific test cases for `examine`. ClhsdbFindPC does make use of it, but not for the addr,addr variant, so it was also omitted for `mem`. I did consider adding a test case for it and still can. I started down that path, but adding an incremental value to a hex String was getting a bit ugly, so I abandoned it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From cjplummer at openjdk.java.net Wed Dec 22 04:00:17 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 22 Dec 2021 04:00:17 GMT Subject: Integrated: 8279024: Remove javascript references from clhsdb.html In-Reply-To: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> References: <9O7-I0zY4FfRcw3ZOXMViqI6WsAF8A1OL1lA6TpfqN0=.b02e8fd9-39e5-480a-9820-1bf3e0629965@github.com> Message-ID: <0hemINMMw6YHQ3ac9O6pnIh_1K2lvjRXDrxxFR6olGM=.e243d67b-ef47-4f9d-883d-9dd2a568b5ae@github.com> On Tue, 21 Dec 2021 02:17:10 GMT, Chris Plummer wrote: > clhsdb no longer supports javascript. Remove some remaining references in the docs. I also removed some script references. This pull request has now been integrated. Changeset: d0ea7c9d Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/d0ea7c9db9cc9ce80b60c2f94c53bb307792fc51 Stats: 52 lines in 2 files changed: 1 ins; 49 del; 2 mod 8279024: Remove javascript references from clhsdb.html Reviewed-by: kevinw, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6903 From kevinw at openjdk.java.net Wed Dec 22 10:12:21 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 22 Dec 2021 10:12:21 GMT Subject: [jdk18] RFR: 8279007: jstatd fails to start because SecurityManager is disabled [v2] In-Reply-To: References: Message-ID: <18yuA3BRsG9RYpZNL8NDqtAfDiwQ2xmmTsFrjQ8os1M=.1904bc62-2dc3-4c7d-898d-2378be7f492c@github.com> On Tue, 21 Dec 2021 20:28:52 GMT, Kevin Walls wrote: >> jstatd now in jdk18 fails to start unless we specifically allow or set a SecurityManager. >> This update to the launcher makefile adds JAVA_ARGS to permit a SecurityManager. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove security manager property from jstatd tests. Regarding the link to #45 I went with "allow" here as it is jstatd's intention to set an RMISecurityManager, not a SecurityManager. We know that is not really different, but this is a late jdk18 change and changing the classes that we load looks like more change than needed here at least. Planning to follow up with a change for jstatd to stop being dependent on the security manager, so warnings are temporary. ------------- PR: https://git.openjdk.java.net/jdk18/pull/53 From serb at openjdk.java.net Wed Dec 22 10:57:37 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 22 Dec 2021 10:57:37 GMT Subject: RFR: 8279134: Fix Amazon copyright in various files Message-ID: This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year): "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." @simonis @phohensee ------------- Commit messages: - Initial fix JDK-8279134 Changes: https://git.openjdk.java.net/jdk/pull/6915/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6915&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279134 Stats: 15 lines in 14 files changed: 0 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6915/head:pull/6915 PR: https://git.openjdk.java.net/jdk/pull/6915 From kevinw at openjdk.java.net Wed Dec 22 11:40:20 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 22 Dec 2021 11:40:20 GMT Subject: [jdk18] Integrated: 8279007: jstatd fails to start because SecurityManager is disabled In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 13:00:26 GMT, Kevin Walls wrote: > jstatd now in jdk18 fails to start unless we specifically allow or set a SecurityManager. > This update to the launcher makefile adds JAVA_ARGS to permit a SecurityManager. This pull request has now been integrated. Changeset: 73414391 Author: Kevin Walls URL: https://git.openjdk.java.net/jdk18/commit/734143918de540382b5a0754bb7be1500b6f3596 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod 8279007: jstatd fails to start because SecurityManager is disabled Reviewed-by: alanb, sspitsyn, mullan ------------- PR: https://git.openjdk.java.net/jdk18/pull/53 From kevinw at openjdk.java.net Wed Dec 22 13:55:13 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 22 Dec 2021 13:55:13 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v4] In-Reply-To: <-PIvfe2jyq9DlohUCI840LBflgwxpYwUr83PST0dq30=.fd1320f5-8dfc-4aec-8ff2-560ecfa7644b@github.com> References: <-PIvfe2jyq9DlohUCI840LBflgwxpYwUr83PST0dq30=.fd1320f5-8dfc-4aec-8ff2-560ecfa7644b@github.com> Message-ID: <-wytKq4HwB_Awh-Q0l-dAETPQzGq4TOlU1xeP5npmIY=.3e2bcaa0-c8a1-4d91-9961-365aaa83eade@github.com> On Tue, 21 Dec 2021 23:12:45 GMT, Chris Plummer wrote: >> clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. >> >> Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. >> >> The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor improvements to help text for mem and examine. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From jwilhelm at openjdk.java.net Wed Dec 22 16:12:51 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 22 Dec 2021 16:12:51 GMT Subject: RFR: Merge jdk18 Message-ID: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com> Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8274315: JFR: One closed state per file or stream - 8271447: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters - 8278987: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in __write_sample_info__ - 8279007: jstatd fails to start because SecurityManager is disabled - 8278508: Enable X86 maskAll instruction pattern for 32 bit JVM. - 8279045: Intrinsics missing vzeroupper instruction The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/6918/files Stats: 260 lines in 21 files changed: 170 ins; 55 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/6918.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6918/head:pull/6918 PR: https://git.openjdk.java.net/jdk/pull/6918 From jwilhelm at openjdk.java.net Wed Dec 22 16:51:03 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 22 Dec 2021 16:51:03 GMT Subject: RFR: Merge jdk18 [v2] In-Reply-To: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com> References: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com> Message-ID: > Forwardport JDK 18 -> JDK 19 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 104 commits: - Merge - 8279063: Consolidate push and push_if_necessary in PreservedMarks Reviewed-by: rkennke, mli, tschatzl - 8279024: Remove javascript references from clhsdb.html Reviewed-by: kevinw, sspitsyn - Merge - 8244670: convert clhsdb "whatis" command from javascript to java Reviewed-by: sspitsyn, kevinw - 8279066: entries.remove(entry) is useless in PKCS12KeyStore Reviewed-by: mullan - Merge - 8279060: Parallel: Remove unused PSVirtualSpace constructors Reviewed-by: mli, sjohanss, tschatzl - 8278396: G1: Initialize the BOT threshold to be region bottom Reviewed-by: tschatzl, sjohanss - 8279043: Some Security Exception Messages Miss Spaces Reviewed-by: weijun - ... and 94 more: https://git.openjdk.java.net/jdk/compare/dfb15c3e...70630b7b ------------- Changes: https://git.openjdk.java.net/jdk/pull/6918/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=01 Stats: 18775 lines in 519 files changed: 14457 ins; 3098 del; 1220 mod Patch: https://git.openjdk.java.net/jdk/pull/6918.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6918/head:pull/6918 PR: https://git.openjdk.java.net/jdk/pull/6918 From jwilhelm at openjdk.java.net Wed Dec 22 16:51:06 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 22 Dec 2021 16:51:06 GMT Subject: Integrated: Merge jdk18 In-Reply-To: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com> References: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com> Message-ID: On Wed, 22 Dec 2021 16:03:43 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: f1fbba23 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/f1fbba23ebdb28a32977241f8e85b60e10878cbc Stats: 260 lines in 21 files changed: 170 ins; 55 del; 35 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/6918 From coleenp at openjdk.java.net Wed Dec 22 17:09:15 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 22 Dec 2021 17:09:15 GMT Subject: [jdk18] RFR: 8278239: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine failed with EXCEPTION_ACCESS_VIOLATION at 0x000000000000000d In-Reply-To: References: Message-ID: <4smM3KY3IgoZOuA3IGp03WVkNV9kkPiWEI5ciwJqHfw=.d09ae931-c8c3-4881-8508-4cf80e91bfee@github.com> On Tue, 21 Dec 2021 20:51:04 GMT, Coleen Phillimore wrote: > This is the fix for https://github.com/openjdk/jdk/pull/6900 retargeted to JDK 18. > > Thanks to @stefank and @fisk for the diagnosis. ZGC is looking at metadata in unloaded nmethods, but redefinition doesn't keep this metadata from being deallocated. Change the iterators that mark metadata in use to walk unloaded nmethods as well as other alive nmethods. > > The test case reproduces the crash on windows if run in an 100 iteration loop. This fix does not crash in the same test. Also ran tier1-6. > > Above testing in progress. Thanks for reviewing, Vladimir and Serguei. ------------- PR: https://git.openjdk.java.net/jdk18/pull/63 From coleenp at openjdk.java.net Wed Dec 22 17:22:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 22 Dec 2021 17:22:19 GMT Subject: [jdk18] Integrated: 8278239: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine failed with EXCEPTION_ACCESS_VIOLATION at 0x000000000000000d In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 20:51:04 GMT, Coleen Phillimore wrote: > This is the fix for https://github.com/openjdk/jdk/pull/6900 retargeted to JDK 18. > > Thanks to @stefank and @fisk for the diagnosis. ZGC is looking at metadata in unloaded nmethods, but redefinition doesn't keep this metadata from being deallocated. Change the iterators that mark metadata in use to walk unloaded nmethods as well as other alive nmethods. > > The test case reproduces the crash on windows if run in an 100 iteration loop. This fix does not crash in the same test. Also ran tier1-6. > > Above testing in progress. This pull request has now been integrated. Changeset: 2be3e7ef Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk18/commit/2be3e7ef1cff1aae6faf1f4f0545d561af48d0ba Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8278239: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine failed with EXCEPTION_ACCESS_VIOLATION at 0x000000000000000d Reviewed-by: kvn, sspitsyn, eosterlund ------------- PR: https://git.openjdk.java.net/jdk18/pull/63 From poonam at openjdk.java.net Wed Dec 22 17:38:16 2021 From: poonam at openjdk.java.net (Poonam Bajaj) Date: Wed, 22 Dec 2021 17:38:16 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v4] In-Reply-To: <-PIvfe2jyq9DlohUCI840LBflgwxpYwUr83PST0dq30=.fd1320f5-8dfc-4aec-8ff2-560ecfa7644b@github.com> References: <-PIvfe2jyq9DlohUCI840LBflgwxpYwUr83PST0dq30=.fd1320f5-8dfc-4aec-8ff2-560ecfa7644b@github.com> Message-ID: On Tue, 21 Dec 2021 23:12:45 GMT, Chris Plummer wrote: >> clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. >> >> Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. >> >> The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor improvements to help text for mem and examine. Looks good to me. ------------- Marked as reviewed by poonam (Committer). PR: https://git.openjdk.java.net/jdk/pull/6902 From cjplummer at openjdk.java.net Wed Dec 22 18:14:40 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 22 Dec 2021 18:14:40 GMT Subject: RFR: 8244669: convert clhsdb "mem" command from javascript to java [v5] In-Reply-To: References: Message-ID: <2FjzvTJDDQQF0nmNftB11_OBSVgcb4JRV33USRa9j2E=.051f6fb4-6f0e-4654-8a43-b6e361aaceb7@github.com> > clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. > > Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. > > The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge - Minor improvements to help text for mem and examine. - Fix issue with address range patterns. For some reason they have always allowed some extra lower case letters at the end of the pattern that just get ignored. I removed support for this since sometimes it resulted in bad address ranges producing an exception rather than a usage() message. - Fix missing return after calling usage() - Change output string we look for so it passes on all platforms. - Add support for clhsdb 'mem' command. ------------- Changes: https://git.openjdk.java.net/jdk/pull/6902/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6902&range=04 Stats: 157 lines in 3 files changed: 121 ins; 28 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6902/head:pull/6902 PR: https://git.openjdk.java.net/jdk/pull/6902 From kevinw at openjdk.java.net Wed Dec 22 18:22:26 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 22 Dec 2021 18:22:26 GMT Subject: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed Message-ID: Remove the use of Security Manager from jstatd. Add use of an ObjectInputFilter to restrict RMI. Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled ..as that is no longer needed. Docs/man page update to follow (JDK-8278619). ------------- Commit messages: - Remove jstad launcher property setting to allow Security Manager. - Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr - Add ObjectInputFilter - Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr - 8272317: jstatd has dependency on Security Manager which needs to be removed Changes: https://git.openjdk.java.net/jdk/pull/6919/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6919&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272317 Stats: 27 lines in 4 files changed: 4 ins; 15 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6919.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6919/head:pull/6919 PR: https://git.openjdk.java.net/jdk/pull/6919 From ecki at zusammenkunft.net Wed Dec 22 19:10:23 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 22 Dec 2021 19:10:23 +0000 Subject: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed In-Reply-To: References: Message-ID: Hello, Is it safe to allow generic proxy objects, could they not execute arbritrary backend methods? Are the invocation handlers filtered indirectly? What about those inner classes, are they stable? Could the whole protocol maybe changed to a different protocol? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: serviceability-dev im Auftrag von Kevin Walls Gesendet: Wednesday, December 22, 2021 7:22:26 PM An: serviceability-dev at openjdk.java.net Betreff: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed Remove the use of Security Manager from jstatd. Add use of an ObjectInputFilter to restrict RMI. Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled ..as that is no longer needed. Docs/man page update to follow (JDK-8278619). ------------- Commit messages: - Remove jstad launcher property setting to allow Security Manager. - Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr - Add ObjectInputFilter - Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr - 8272317: jstatd has dependency on Security Manager which needs to be removed Changes: https://git.openjdk.java.net/jdk/pull/6919/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6919&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272317 Stats: 27 lines in 4 files changed: 4 ins; 15 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6919.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6919/head:pull/6919 PR: https://git.openjdk.java.net/jdk/pull/6919 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.java.net Wed Dec 22 21:44:12 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 22 Dec 2021 21:44:12 GMT Subject: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed In-Reply-To: References: Message-ID: <3Z6pFX6xVhKhEjki2Hoyniz26-vYZNd4IfN7-xkzduc=.1ff636ec-749c-4ed7-8a9b-db206d4191e1@github.com> On Wed, 22 Dec 2021 18:14:43 GMT, Kevin Walls wrote: > Remove the use of Security Manager from jstatd. > Add use of an ObjectInputFilter to restrict RMI. > > Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled > ..as that is no longer needed. > > Docs/man page update to follow (JDK-8278619). src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 51: > 49: private static RemoteHost remoteHost; > 50: > 51: private static final String rmiFilterPattern = "sun.jvmstat.monitor.remote.RemoteVm;com.sun.proxy.jdk.proxy1.$Proxy1;com.sun.proxy.jdk.proxy1.$Proxy2;java.lang.reflect.Proxy;java.rmi.server.RemoteObjectInvocationHandler;java.rmi.server.RemoteObject;!*"; The class name of the dynamic proxy is generated at runtime and can be different. As Bernd commented, the proxy classes cannot/should not be listed in the filter pattern. ------------- PR: https://git.openjdk.java.net/jdk/pull/6919 From kevinw at openjdk.java.net Wed Dec 22 22:04:10 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 22 Dec 2021 22:04:10 GMT Subject: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed In-Reply-To: <3Z6pFX6xVhKhEjki2Hoyniz26-vYZNd4IfN7-xkzduc=.1ff636ec-749c-4ed7-8a9b-db206d4191e1@github.com> References: <3Z6pFX6xVhKhEjki2Hoyniz26-vYZNd4IfN7-xkzduc=.1ff636ec-749c-4ed7-8a9b-db206d4191e1@github.com> Message-ID: <3cQSjb-g6SOf8drmfEzfycclauKcJgOYvYS9PM7XdnU=.dff055e4-7e61-46b1-bc20-b58eb45fe834@github.com> On Wed, 22 Dec 2021 21:41:13 GMT, Mandy Chung wrote: >> Remove the use of Security Manager from jstatd. >> Add use of an ObjectInputFilter to restrict RMI. >> >> Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled >> ..as that is no longer needed. >> >> Docs/man page update to follow (JDK-8278619). > > src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 51: > >> 49: private static RemoteHost remoteHost; >> 50: >> 51: private static final String rmiFilterPattern = "sun.jvmstat.monitor.remote.RemoteVm;com.sun.proxy.jdk.proxy1.$Proxy1;com.sun.proxy.jdk.proxy1.$Proxy2;java.lang.reflect.Proxy;java.rmi.server.RemoteObjectInvocationHandler;java.rmi.server.RemoteObject;!*"; > > The class name of the dynamic proxy is generated at runtime and can be different. As Bernd commented, the proxy classes cannot/should not be listed in the filter pattern. OK thanks - I was trying the minimal pattern to overcome rejections such as the following, captured in logs on different runs: ObjectInputFilter REJECTED: class com.sun.proxy.jdk.proxy1.$Proxy1, array length: -1, nRefs: 2, depth: 1, bytes: 84, ex: n/a ObjectInputFilter REJECTED: class com.sun.proxy.jdk.proxy1.$Proxy2, array length: -1, nRefs: 2, depth: 1, bytes: 84, ex: n/a ------------- PR: https://git.openjdk.java.net/jdk/pull/6919 From cjplummer at openjdk.java.net Wed Dec 22 23:06:16 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 22 Dec 2021 23:06:16 GMT Subject: Integrated: 8244669: convert clhsdb "mem" command from javascript to java In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 01:26:07 GMT, Chris Plummer wrote: > clhsdb lost support for the "mem" command when javascript support was removed from SA. This PR is re-adding it by implementing it in Java. The description of the CR contains all the details. > > Regarding the clhsdb.html changes for the "examine" command, they are just correctly specifying the existing syntax. No change was actually made to the syntax. > > The changes made to the "examine" command are part of a consolidation effort to better share code between "examine" and "mem". "examine" has no functional changes. This pull request has now been integrated. Changeset: eaefb1a1 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/eaefb1a1ed9edea440628e3a5c5483ebd52bfcb0 Stats: 157 lines in 3 files changed: 121 ins; 28 del; 8 mod 8244669: convert clhsdb "mem" command from javascript to java Reviewed-by: sspitsyn, kevinw, poonam ------------- PR: https://git.openjdk.java.net/jdk/pull/6902 From cjplummer at openjdk.java.net Thu Dec 23 03:38:31 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 23 Dec 2021 03:38:31 GMT Subject: RFR: 8279194: Add Annotated Memory Viewer feature to SA's HSDB Message-ID: HSDB has a Memory Viewer feature that brings up a window that shows the memory contents in a specific address range. It basically looks just like the clhsdb "mem" output. The recently revived "mem" command (see [JDK-824466](https://bugs.openjdk.java.net/browse/JDK-8244669) and PR #6902) adds a -v options which causes PointerFinder (aka findpc) to be called on each value in memory to provide details about what the value points to (if it is an address). This PR adds this same feature to HSDB by adding a new Annotated Memory Viewer window. See the [this image](https://bugs.openjdk.java.net/secure/attachment/97439/memory_viewer.png) which shows the current Memory Viewer window, and just below it the new Annotated Memory Viewer window showing the same address range. A couple of implementation notes. Both types of memory viewers share the MemoryPanel class. The traditional viewer uses two columns, one for the address and one for its contents. The annotated viewer uses just one column which contains the entire line. For example: 0x00007f7eb010c330: 0x00007f7eb6c9dfb0 vtable for os::PlatformMonitor + 0x10 This approach was chosen rather than using 3 columns because it was a difficult to get the first two columns to be just wide enough for the 64-bit values while having the 3rd column be a long line of text. You end up with a lot of wasted space in the first two columns as you make the window wider while trying to get all the text of the 3rd column into view. Regarding the changes in MemoryPanel.handleImport(), Memory Viewer supports clicking on a value that's an address and dragging it back onto the window to start displaying memory at that address. This dropped text ends up being processed by MemoryPanel.handleImport(). When you try this with Annotated Memory Viewer, you end up with the entire line being passed to MemoryPanel.handleImport(), not just an address (one downside of going with just 1 column instead of 3). So the changes in MemoryPanel.handleImport() detect this and pull the desired address out of the string. ------------- Commit messages: - Added Annotated Memory Viewer support. Changes: https://git.openjdk.java.net/jdk/pull/6923/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6923&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279194 Stats: 83 lines in 3 files changed: 66 ins; 2 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/6923.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6923/head:pull/6923 PR: https://git.openjdk.java.net/jdk/pull/6923 From cjplummer at openjdk.java.net Thu Dec 23 03:53:24 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 23 Dec 2021 03:53:24 GMT Subject: RFR: 8279119: src/jdk.hotspot.agent/doc/index.html file contains references to scripts that no longer exist Message-ID: <65JKYTnJ84wT9QFc_wrnufgTC7TsfqxfqFrogEOfkIk=.d96ce084-ba3c-4405-867a-9e526925adf4@github.com> The SA src/jdk.hotspot.agent/doc/index.html file contains a table of SA scripts and their descriptions. All of these scripts are now gone. They were used to make it easier to launch what today we would call SA tools. Now all these tools are launched as sub-commands of the jhsdb command, which has its own man page. I also did some other minor fixes and cleanups. ------------- Commit messages: - Remove reference to scripts and other minor cleanups. Changes: https://git.openjdk.java.net/jdk/pull/6924/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6924&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279119 Stats: 189 lines in 1 file changed: 0 ins; 165 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/6924.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6924/head:pull/6924 PR: https://git.openjdk.java.net/jdk/pull/6924 From cjplummer at openjdk.java.net Thu Dec 23 04:52:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 23 Dec 2021 04:52:47 GMT Subject: RFR: 8250801: Add clhsdb "threadcontext" command Message-ID: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> SA has the ability to fetch the thread's registers via the thread context. It would be nice to allow access to the registers from clhsdb. This plays in well with the enhancements being done to PointerFinder as part of JDK-8247514. Many of the register values will then be automatically displayed as symbols, Methods, Threads, stack offsets, nmethods, interpreter codelets, etc. During some recent debugging I did I found it useful to dump a thread's registers in this manner. Although in this case I was inlining the code in the part of SA where I wanted to see the registers, having it as a clhsdb command would not only be useful to user, but also useful when debugging SA because it would serve as a code snippet to copy-n-paste where needed. The syntax is: threadcontext [-v] { -a | id } Where -a displays all threads, and "id" is used to display a specific thread. This is the same argument syntax as some other commands that let you choose all threads or just one thread, such as the "thread" and "where" commands. -v just means more verbose output, whereas without it for the most part each register printed will just take up one line. ------------- Commit messages: - Add support for clhsdb threadcontext commad. Changes: https://git.openjdk.java.net/jdk/pull/6925/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6925&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250801 Stats: 166 lines in 3 files changed: 163 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6925/head:pull/6925 PR: https://git.openjdk.java.net/jdk/pull/6925 From kevinw at openjdk.java.net Thu Dec 23 10:07:14 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 23 Dec 2021 10:07:14 GMT Subject: RFR: 8279119: src/jdk.hotspot.agent/doc/index.html file contains references to scripts that no longer exist In-Reply-To: <65JKYTnJ84wT9QFc_wrnufgTC7TsfqxfqFrogEOfkIk=.d96ce084-ba3c-4405-867a-9e526925adf4@github.com> References: <65JKYTnJ84wT9QFc_wrnufgTC7TsfqxfqFrogEOfkIk=.d96ce084-ba3c-4405-867a-9e526925adf4@github.com> Message-ID: On Thu, 23 Dec 2021 03:45:31 GMT, Chris Plummer wrote: > The SA src/jdk.hotspot.agent/doc/index.html file contains a table of SA scripts and their descriptions. All of these scripts are now gone. They were used to make it easier to launch what today we would call SA tools. Now all these tools are launched as sub-commands of the jhsdb command, which has its own man page. > > I also did some other minor fixes and cleanups. > > The rendered html can be found here: > https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/53d2753cf32ef65ddea631062ca8641c3d19f27b/src/jdk.hotspot.agent/doc/index.html Nice refresh/cleanup. src/jdk.hotspot.agent/doc/index.html line 51: > 49:

> 50: When a core dump is moved from the machine where it was produced to a > 51: difference machine, it may not always be possible for SA to debug it. "difference machine" rather than "different machine " is not your typo but if you had time while we are here... 8-) ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/6924 From cjplummer at openjdk.java.net Thu Dec 23 17:58:56 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 23 Dec 2021 17:58:56 GMT Subject: RFR: 8279119: src/jdk.hotspot.agent/doc/index.html file contains references to scripts that no longer exist [v2] In-Reply-To: <65JKYTnJ84wT9QFc_wrnufgTC7TsfqxfqFrogEOfkIk=.d96ce084-ba3c-4405-867a-9e526925adf4@github.com> References: <65JKYTnJ84wT9QFc_wrnufgTC7TsfqxfqFrogEOfkIk=.d96ce084-ba3c-4405-867a-9e526925adf4@github.com> Message-ID: > The SA src/jdk.hotspot.agent/doc/index.html file contains a table of SA scripts and their descriptions. All of these scripts are now gone. They were used to make it easier to launch what today we would call SA tools. Now all these tools are launched as sub-commands of the jhsdb command, which has its own man page. > > I also did some other minor fixes and cleanups. > > The rendered html can be found here: > https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/dc0311f0a60ae550b01a3885d74fa23288df37d1/src/jdk.hotspot.agent/doc/index.html Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Fix minor typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6924/files - new: https://git.openjdk.java.net/jdk/pull/6924/files/53d2753c..dc0311f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6924&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6924&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6924.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6924/head:pull/6924 PR: https://git.openjdk.java.net/jdk/pull/6924 From cjplummer at openjdk.java.net Thu Dec 23 17:58:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 23 Dec 2021 17:58:59 GMT Subject: RFR: 8279119: src/jdk.hotspot.agent/doc/index.html file contains references to scripts that no longer exist [v2] In-Reply-To: References: <65JKYTnJ84wT9QFc_wrnufgTC7TsfqxfqFrogEOfkIk=.d96ce084-ba3c-4405-867a-9e526925adf4@github.com> Message-ID: On Thu, 23 Dec 2021 10:03:54 GMT, Kevin Walls wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix minor typo > > src/jdk.hotspot.agent/doc/index.html line 51: > >> 49:

>> 50: When a core dump is moved from the machine where it was produced to a >> 51: difference machine, it may not always be possible for SA to debug it. > > "difference machine" rather than "different machine " is not your typo but if you had time while we are here... 8-) Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/6924 From xliu at openjdk.java.net Thu Dec 23 21:40:16 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 23 Dec 2021 21:40:16 GMT Subject: RFR: 8279134: Fix Amazon copyright in various files In-Reply-To: References: Message-ID: On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov wrote: > This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 > > Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year): > > "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." > > @simonis @phohensee LGTM. I am not a reviewer. Need other reviewers to approve it. ------------- Marked as reviewed by xliu (Committer). PR: https://git.openjdk.java.net/jdk/pull/6915 From phh at openjdk.java.net Thu Dec 23 22:47:11 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Thu, 23 Dec 2021 22:47:11 GMT Subject: RFR: 8279134: Fix Amazon copyright in various files In-Reply-To: References: Message-ID: <7ozNgn5YKtgY8XsZYqexriYLPTVz-yZJJcEs2cxSfuQ=.d731d200-f8ef-4999-9e14-f6be115bdf14@github.com> On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov wrote: > This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 > > Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year): > > "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." > > @simonis @phohensee Lgtm. ------------- Marked as reviewed by phh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6915 From serb at openjdk.java.net Fri Dec 24 00:50:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 24 Dec 2021 00:50:57 GMT Subject: RFR: 8279134: Fix Amazon copyright in various files [v2] In-Reply-To: References: Message-ID: <4TylKnNJehPUtdh9y0wh4Cgq93jq4y4mEQfHEKBJdmA=.907bb3ab-9b11-40da-8957-dfef5f3e21e4@github.com> > This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 > > Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year): > > "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." > > @simonis @phohensee Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8279134 - Initial fix JDK-8279134 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6915/files - new: https://git.openjdk.java.net/jdk/pull/6915/files/cb05f5bb..52c5d9c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6915&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6915&range=00-01 Stats: 619 lines in 42 files changed: 446 ins; 100 del; 73 mod Patch: https://git.openjdk.java.net/jdk/pull/6915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6915/head:pull/6915 PR: https://git.openjdk.java.net/jdk/pull/6915 From sspitsyn at openjdk.java.net Fri Dec 24 02:14:17 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 24 Dec 2021 02:14:17 GMT Subject: RFR: 8279119: src/jdk.hotspot.agent/doc/index.html file contains references to scripts that no longer exist [v2] In-Reply-To: References: <65JKYTnJ84wT9QFc_wrnufgTC7TsfqxfqFrogEOfkIk=.d96ce084-ba3c-4405-867a-9e526925adf4@github.com> Message-ID: On Thu, 23 Dec 2021 17:58:56 GMT, Chris Plummer wrote: >> The SA src/jdk.hotspot.agent/doc/index.html file contains a table of SA scripts and their descriptions. All of these scripts are now gone. They were used to make it easier to launch what today we would call SA tools. Now all these tools are launched as sub-commands of the jhsdb command, which has its own man page. >> >> I also did some other minor fixes and cleanups. >> >> The rendered html can be found here: >> https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/dc0311f0a60ae550b01a3885d74fa23288df37d1/src/jdk.hotspot.agent/doc/index.html > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix minor typo Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6924 From sspitsyn at openjdk.java.net Fri Dec 24 02:35:15 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 24 Dec 2021 02:35:15 GMT Subject: RFR: 8250801: Add clhsdb "threadcontext" command In-Reply-To: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> References: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> Message-ID: On Thu, 23 Dec 2021 04:06:58 GMT, Chris Plummer wrote: > SA has the ability to fetch the thread's registers via the thread context. It would be nice to allow access to the registers from clhsdb. This plays in well with the enhancements being done to PointerFinder as part of JDK-8247514. Many of the register values will then be automatically displayed as symbols, Methods, Threads, stack offsets, nmethods, interpreter codelets, etc. > > During some recent debugging I did I found it useful to dump a thread's registers in this manner. Although in this case I was inlining the code in the part of SA where I wanted to see the registers, having it as a clhsdb command would not only be useful to user, but also useful when debugging SA because it would serve as a code snippet to copy-n-paste where needed. > > The syntax is: > > threadcontext [-v] { -a | id } > > Where -a displays all threads, and "id" is used to display a specific thread. This is the same argument syntax as some other commands that let you choose all threads or just one thread, such as the "thread" and "where" commands. -v just means more verbose output, whereas without it for the most part each register printed will just take up one line. Chris, I only have one question (inlined). Other than that it looks good to me. Thanks, Serguei test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java line 34: > 32: * @test > 33: * @bug 8190198 > 34: * @summary Test clhsdb where command Should the bug number be 8250801 and the summary say "Test clhsdb threadcontext command"? ------------- PR: https://git.openjdk.java.net/jdk/pull/6925 From cjplummer at openjdk.java.net Fri Dec 24 02:47:16 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 24 Dec 2021 02:47:16 GMT Subject: RFR: 8250801: Add clhsdb "threadcontext" command In-Reply-To: References: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> Message-ID: On Fri, 24 Dec 2021 02:30:43 GMT, Serguei Spitsyn wrote: >> SA has the ability to fetch the thread's registers via the thread context. It would be nice to allow access to the registers from clhsdb. This plays in well with the enhancements being done to PointerFinder as part of JDK-8247514. Many of the register values will then be automatically displayed as symbols, Methods, Threads, stack offsets, nmethods, interpreter codelets, etc. >> >> During some recent debugging I did I found it useful to dump a thread's registers in this manner. Although in this case I was inlining the code in the part of SA where I wanted to see the registers, having it as a clhsdb command would not only be useful to user, but also useful when debugging SA because it would serve as a code snippet to copy-n-paste where needed. >> >> The syntax is: >> >> threadcontext [-v] { -a | id } >> >> Where -a displays all threads, and "id" is used to display a specific thread. This is the same argument syntax as some other commands that let you choose all threads or just one thread, such as the "thread" and "where" commands. -v just means more verbose output, whereas without it for the most part each register printed will just take up one line. > > test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java line 34: > >> 32: * @test >> 33: * @bug 8190198 >> 34: * @summary Test clhsdb where command > > Should the bug number be 8250801 and the summary say "Test clhsdb threadcontext command"? Copy-n-paste error. I think actually @bug should be removed since this test was not created to reproduce a bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/6925 From sspitsyn at openjdk.java.net Fri Dec 24 03:11:16 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 24 Dec 2021 03:11:16 GMT Subject: RFR: 8279194: Add Annotated Memory Viewer feature to SA's HSDB In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 03:31:44 GMT, Chris Plummer wrote: > HSDB has a Memory Viewer feature that brings up a window that shows the memory contents in a specific address range. It basically looks just like the clhsdb "mem" output. The recently revived "mem" command (see [JDK-824466](https://bugs.openjdk.java.net/browse/JDK-8244669) and PR #6902) adds a -v options which causes PointerFinder (aka findpc) to be called on each value in memory to provide details about what the value points to (if it is an address). This PR adds this same feature to HSDB by adding a new Annotated Memory Viewer window. See the [this image](https://bugs.openjdk.java.net/secure/attachment/97439/memory_viewer.png) which shows the current Memory Viewer window, and just below it the new Annotated Memory Viewer window showing the same address range. > > A couple of implementation notes. Both types of memory viewers share the MemoryPanel class. The traditional viewer uses two columns, one for the address and one for its contents. The annotated viewer uses just one column which contains the entire line. For example: > > 0x00007f7eb010c330: 0x00007f7eb6c9dfb0 vtable for os::PlatformMonitor + 0x10 > > This approach was chosen rather than using 3 columns because it was a difficult to get the first two columns to be just wide enough for the 64-bit values while having the 3rd column be a long line of text. You end up with a lot of wasted space in the first two columns as you make the window wider while trying to get all the text of the 3rd column into view. > > Regarding the changes in MemoryPanel.handleImport(), Memory Viewer supports clicking on a value that's an address and dragging it back onto the window to start displaying memory at that address. This dropped text ends up being processed by MemoryPanel.handleImport(). When you try this with Annotated Memory Viewer, you end up with the entire line being passed to MemoryPanel.handleImport(), not just an address (one downside of going with just 1 column instead of 3). So the changes in MemoryPanel.handleImport() detect this and pull the desired address out of the string. It seems to be a nice feature introduced with this. Looks good to me. Just one nit inlined. Thanks, Serguei src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/MemoryPanel.java line 140: > 138: Address addr = bigIntToAddress(bigaddr); > 139: > 140: col1 = bigIntToHexString(bigaddr); Nit: This can be simplified just a little bit by moving the lines 137-138 above line 134. So, it will be like this: BigInteger bigaddr = startVal.add(new BigInteger(Integer.toString((row * addressSize)))); Address addr = bigIntToAddress(bigaddr); String col1 = bigIntToHexString(bigaddr); String col2 = unmappedAddrString; String col3 = ""; ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6923 From sspitsyn at openjdk.java.net Fri Dec 24 03:13:11 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 24 Dec 2021 03:13:11 GMT Subject: RFR: 8250801: Add clhsdb "threadcontext" command In-Reply-To: References: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> Message-ID: On Fri, 24 Dec 2021 02:44:10 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java line 34: >> >>> 32: * @test >>> 33: * @bug 8190198 >>> 34: * @summary Test clhsdb where command >> >> Should the bug number be 8250801 and the summary say "Test clhsdb threadcontext command"? > > Copy-n-paste error. I think actually @bug should be removed since this test was not created to reproduce a bug. Yes, I'm okay with that. ------------- PR: https://git.openjdk.java.net/jdk/pull/6925 From kevinw at openjdk.java.net Fri Dec 24 11:34:15 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 24 Dec 2021 11:34:15 GMT Subject: RFR: 8250801: Add clhsdb "threadcontext" command In-Reply-To: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> References: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> Message-ID: On Thu, 23 Dec 2021 04:06:58 GMT, Chris Plummer wrote: > SA has the ability to fetch the thread's registers via the thread context. It would be nice to allow access to the registers from clhsdb. This plays in well with the enhancements being done to PointerFinder as part of JDK-8247514. Many of the register values will then be automatically displayed as symbols, Methods, Threads, stack offsets, nmethods, interpreter codelets, etc. > > During some recent debugging I did I found it useful to dump a thread's registers in this manner. Although in this case I was inlining the code in the part of SA where I wanted to see the registers, having it as a clhsdb command would not only be useful to user, but also useful when debugging SA because it would serve as a code snippet to copy-n-paste where needed. > > The syntax is: > > threadcontext [-v] { -a | id } > > Where -a displays all threads, and "id" is used to display a specific thread. This is the same argument syntax as some other commands that let you choose all threads or just one thread, such as the "thread" and "where" commands. -v just means more verbose output, whereas without it for the most part each register printed will just take up one line. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 489: > 487: for (int r = 0; r < tc.getNumRegisters(); r++) { > 488: Address regAddr = tc.getRegisterAsAddress(r); > 489: System.out.format("Register(%s): %s", tc.getRegisterName(r), regAddr); Would you consider just printing name = value, rather than printing the word Register many times? 8-) ------------- PR: https://git.openjdk.java.net/jdk/pull/6925 From kevinw at openjdk.java.net Fri Dec 24 11:37:19 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 24 Dec 2021 11:37:19 GMT Subject: RFR: 8250801: Add clhsdb "threadcontext" command In-Reply-To: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> References: <-l18eeCbuWXGi1DIYDXGTM9ZI_JEZJBxXTiIvIXe63A=.98f32061-d88f-49c2-a058-659e280cf0f7@github.com> Message-ID: On Thu, 23 Dec 2021 04:06:58 GMT, Chris Plummer wrote: > SA has the ability to fetch the thread's registers via the thread context. It would be nice to allow access to the registers from clhsdb. This plays in well with the enhancements being done to PointerFinder as part of JDK-8247514. Many of the register values will then be automatically displayed as symbols, Methods, Threads, stack offsets, nmethods, interpreter codelets, etc. > > During some recent debugging I did I found it useful to dump a thread's registers in this manner. Although in this case I was inlining the code in the part of SA where I wanted to see the registers, having it as a clhsdb command would not only be useful to user, but also useful when debugging SA because it would serve as a code snippet to copy-n-paste where needed. > > The syntax is: > > threadcontext [-v] { -a | id } > > Where -a displays all threads, and "id" is used to display a specific thread. This is the same argument syntax as some other commands that let you choose all threads or just one thread, such as the "thread" and "where" commands. -v just means more verbose output, whereas without it for the most part each register printed will just take up one line. Looks useful to expose this info if we have it! ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/6925 From ysuenaga at openjdk.java.net Fri Dec 24 13:22:20 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 24 Dec 2021 13:22:20 GMT Subject: RFR: 8279194: Add Annotated Memory Viewer feature to SA's HSDB In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 03:31:44 GMT, Chris Plummer wrote: > HSDB has a Memory Viewer feature that brings up a window that shows the memory contents in a specific address range. It basically looks just like the clhsdb "mem" output. The recently revived "mem" command (see [JDK-824466](https://bugs.openjdk.java.net/browse/JDK-8244669) and PR #6902) adds a -v options which causes PointerFinder (aka findpc) to be called on each value in memory to provide details about what the value points to (if it is an address). This PR adds this same feature to HSDB by adding a new Annotated Memory Viewer window. See the [this image](https://bugs.openjdk.java.net/secure/attachment/97439/memory_viewer.png) which shows the current Memory Viewer window, and just below it the new Annotated Memory Viewer window showing the same address range. > > A couple of implementation notes. Both types of memory viewers share the MemoryPanel class. The traditional viewer uses two columns, one for the address and one for its contents. The annotated viewer uses just one column which contains the entire line. For example: > > 0x00007f7eb010c330: 0x00007f7eb6c9dfb0 vtable for os::PlatformMonitor + 0x10 > > This approach was chosen rather than using 3 columns because it was a difficult to get the first two columns to be just wide enough for the 64-bit values while having the 3rd column be a long line of text. You end up with a lot of wasted space in the first two columns as you make the window wider while trying to get all the text of the 3rd column into view. > > Regarding the changes in MemoryPanel.handleImport(), Memory Viewer supports clicking on a value that's an address and dragging it back onto the window to start displaying memory at that address. This dropped text ends up being processed by MemoryPanel.handleImport(). When you try this with Annotated Memory Viewer, you end up with the entire line being passed to MemoryPanel.handleImport(), not just an address (one downside of going with just 1 column instead of 3). So the changes in MemoryPanel.handleImport() detect this and pull the desired address out of the string. It's a nice feature to me! ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6923 From smarks at openjdk.java.net Fri Dec 24 20:17:22 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 24 Dec 2021 20:17:22 GMT Subject: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed In-Reply-To: <3cQSjb-g6SOf8drmfEzfycclauKcJgOYvYS9PM7XdnU=.dff055e4-7e61-46b1-bc20-b58eb45fe834@github.com> References: <3Z6pFX6xVhKhEjki2Hoyniz26-vYZNd4IfN7-xkzduc=.1ff636ec-749c-4ed7-8a9b-db206d4191e1@github.com> <3cQSjb-g6SOf8drmfEzfycclauKcJgOYvYS9PM7XdnU=.dff055e4-7e61-46b1-bc20-b58eb45fe834@github.com> Message-ID: On Wed, 22 Dec 2021 22:01:00 GMT, Kevin Walls wrote: >> src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 51: >> >>> 49: private static RemoteHost remoteHost; >>> 50: >>> 51: private static final String rmiFilterPattern = "sun.jvmstat.monitor.remote.RemoteVm;com.sun.proxy.jdk.proxy1.$Proxy1;com.sun.proxy.jdk.proxy1.$Proxy2;java.lang.reflect.Proxy;java.rmi.server.RemoteObjectInvocationHandler;java.rmi.server.RemoteObject;!*"; >> >> The class name of the dynamic proxy is generated at runtime and can be different. As Bernd commented, the proxy classes cannot/should not be listed in the filter pattern. > > OK thanks - I was trying the minimal pattern to overcome rejections such as the following, captured in logs on different runs: > > ObjectInputFilter REJECTED: class com.sun.proxy.jdk.proxy1.$Proxy1, array length: -1, nRefs: 2, depth: 1, bytes: 84, ex: n/a > > ObjectInputFilter REJECTED: class com.sun.proxy.jdk.proxy1.$Proxy2, array length: -1, nRefs: 2, depth: 1, bytes: 84, ex: n/a I think the proxy classes need to be there. The `RemoteHost` API has a parameter of type `RemoteVm` which is a stub to an RMI remote object, which consists of a proxy and a handler. The proxy's interface list is filtered by the serialization filter so somebody can't just pass a proxy for anything. The name of the proxy class probably does need to be wildcarded though. ------------- PR: https://git.openjdk.java.net/jdk/pull/6919 From serb at openjdk.java.net Sun Dec 26 22:14:15 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 26 Dec 2021 22:14:15 GMT Subject: Integrated: 8279134: Fix Amazon copyright in various files In-Reply-To: References: Message-ID: On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov wrote: > This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 > > Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year): > > "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." > > @simonis @phohensee This pull request has now been integrated. Changeset: 7fea1032 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/7fea10327ed27fcf8eae474ca5b15c3b4bafff2a Stats: 15 lines in 14 files changed: 0 ins; 1 del; 14 mod 8279134: Fix Amazon copyright in various files Reviewed-by: xliu, phh ------------- PR: https://git.openjdk.java.net/jdk/pull/6915 From hedongbo at huawei.com Thu Dec 30 03:58:13 2021 From: hedongbo at huawei.com (hedongbo) Date: Thu, 30 Dec 2021 03:58:13 +0000 Subject: [8u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load In-Reply-To: <4dd54b5a943842868ec4b1c8aed2dbf3@huawei.com> References: <4dd54b5a943842868ec4b1c8aed2dbf3@huawei.com> Message-ID: <348b7a3fcfef4d66bb8f0a4c085e20d9@huawei.com> This problem has affected the customer's use at present. Can anyone help to take a look? Thanks. Thanks, hedongbo From: hedongbo Sent: Friday, December 17, 2021 9:35 AM To: jdk8u-dev Cc: 'serviceability-dev at openjdk.java.net' Subject: [8u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load Hi, Please review the backport of JDK-8173361 to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8173361 11u commit: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/99bdef096320 8u webrev: https://cr.openjdk.java.net/~dongbohe/8173361/webrev.00/ This patch doesn't apply cleanly. I turned NoSafepointVerifier to No_Safepoint_Verifier because JDK- 8146690[1] changed the naming convention. I removed the mutexLocker.cpp changeset because JDK-8047290[2] does not exist in 8. I added the CLDClosure* to ServiceThread::oops_do because JDK- 8154580[3] does not exist in 8. Tested with tier1. No regression in tests. Follow-up fix JDK-8235218[4] is planned to be backported as well. [1] https://bugs.openjdk.java.net/browse/JDK-8146690 [2] https://bugs.openjdk.java.net/browse/JDK-8047290 [3] https://bugs.openjdk.java.net/browse/JDK-8154580 [4] https://bugs.openjdk.java.net/browse/JDK-8235218 Thanks, hedongbo -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Dec 30 08:29:52 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 30 Dec 2021 08:29:52 +0000 Subject: OpenJDK SADebugDTest.java test : handling of "Address already in use" Message-ID: Hello, I have a question regarding the test SADebugDTest.java . The test https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java seems to handle already cases where "Address already in use" is found in the output (see line 120 ). However in our nightly test, the SADebugDTest.java fails with this output : LingeredApp stdout: []; LingeredApp stderr: [] LingeredApp exitValue = 0 ----------System.err:(17/1318)---------- [debugd] Attaching to process ID 372 and starting RMI services, please wait... [debugd] Error attaching to process or starting server: sun.jvm.hotspot.debugger.DebuggerException: java.rmi.server.ExportException: Port already in use: 39399; nested exception is: [debugd] java.net.BindException: Address already in use [debugd] at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:384) java.lang.RuntimeException: Expected message "RMI connector is bound to port 39399" is not found in the output. at SADebugDTest.testWithPid(SADebugDTest.java:132) at SADebugDTest.runTests(SADebugDTest.java:68) at SADebugDTest.main(SADebugDTest.java:60) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected message "RMI connector is bound to port 39399" is not found in the output. JavaTest Message: shutting down test Looks like the ADDRESS_ALREADY_IN_USE string is checked below; however later in the coding portInUse is not checked but the RuntimeException "Expected message . . ." is thrown : Process debugd = startProcess("debugd", pb, null, l -> { if (!useRmiPort && l.contains(GOLDEN)) { testResult = true; } else if (useRmiPort && l.contains(RMI_CONNECTOR_IS_BOUND + finalRmiPort)) { testResult = true; } else if (l.contains(ADDRESS_ALREADY_IN_USE)) { portInUse = true; } return (l.contains(GOLDEN) || portInUse); }, 20, TimeUnit.SECONDS); // If we are here, this means we have received the golden line and the test has passed // The debugd remains running, we have to kill it debugd.destroy(); debugd.waitFor(); if (!testResult) { throw new RuntimeException("Expected message \"" + RMI_CONNECTOR_IS_BOUND + rmiPort + "\" is not found in the output."); } } while (portInUse); // Repeat the test if the port is already in use Is this really intended ? from the comments in the test I had the impression that in case of "port in use" / "address already in use" the test should be repeated ? Otherwise if this is intended, should we flag the test with @key intermittent ? Thanks and best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From suenaga at oss.nttdata.com Fri Dec 31 09:49:02 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 31 Dec 2021 18:49:02 +0900 Subject: OpenJDK SADebugDTest.java test : handling of "Address already in use" In-Reply-To: References: Message-ID: <1ad4d98c-b779-5402-8a6a-387996f8984e@oss.nttdata.com> Hi Matthias, I think SADebugDTest.java wouldn't work that we expect. ``` 114 Process debugd = startProcess("debugd", pb, null, 115 l -> { 116 if (!useRmiPort && l.contains(GOLDEN)) { 117 testResult = true; 118 } else if (useRmiPort && l.contains(RMI_CONNECTOR_IS_BOUND + finalRmiPort)) { 119 testResult = true; 120 } else if (l.contains(ADDRESS_ALREADY_IN_USE)) { 121 portInUse = true; 122 } 123 return (l.contains(GOLDEN) || portInUse); 124 }, 20, TimeUnit.SECONDS); ``` `testResult` and `portInUse` are important variables in this logic, however they are overwritten in lambda expression - they won't affect to the caller. (I wonder why the test can compile without any error...) Anyway, we should fix it. I will fix and will send PR. Thanks, Yasumasa On 2021/12/30 17:29, Baesken, Matthias wrote: > Hello, I have a question regarding the test? SADebugDTest.java . > > The test > > https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java > > seems to handle already cases where ?Address already in use? is found in the output (see line 120 ). > > However in our nightly test,? the SADebugDTest.java?? fails with this output : > > LingeredApp stdout: []; > > LingeredApp stderr: [] > > LingeredApp exitValue = 0 > > ----------System.err:(17/1318)---------- > > [debugd] Attaching to process ID 372 and starting RMI services, please wait... > > [debugd] Error attaching to process or starting server: sun.jvm.hotspot.debugger.DebuggerException: java.rmi.server.ExportException: Port already in use: 39399; nested exception is: > > *[debugd] java.net.BindException: Address already in use* > > [debugd] at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:384) > > java.lang.RuntimeException: Expected message "RMI connector is bound to port 39399" is not found in the output. > > ? at SADebugDTest.testWithPid(SADebugDTest.java:132) > > ? at SADebugDTest.runTests(SADebugDTest.java:68) > > ? at SADebugDTest.main(SADebugDTest.java:60) > > ? at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > > ? at java.base/java.lang.reflect.Method.invoke(Method.java:577) > > ? at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > ? at java.base/java.lang.Thread.run(Thread.java:833) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected message "RMI connector is bound to port 39399" is not found in the output. > > JavaTest Message: shutting down test > > Looks like? the *ADDRESS_ALREADY_IN_USE *string is checked below;? however later in the coding? portInUse? is not checked but? the RuntimeException ??Expected message . . .?? is thrown : > > ??????????????? Process debugd = startProcess("debugd", pb, null, > > ??????????????????????? l -> { > > ??????????????????????????? if (!useRmiPort && l.contains(GOLDEN)) { > > ??????????????????????????????? testResult = true; > > ??????????????????????????? } else if (useRmiPort && l.contains(RMI_CONNECTOR_IS_BOUND + finalRmiPort)) { > > ????????????????????????????? ??testResult = true; > > *??????????????????????????? } else if (l.contains(ADDRESS_ALREADY_IN_USE)) {* > > *??????????????????????????????? portInUse = true;* > > ??????????????????????????? } > > ??????????????????????????? return (l.contains(GOLDEN) || portInUse); > > ??????? ????????????????}, 20, TimeUnit.SECONDS); > > ??????????????? // If we are here, this means we have received the golden line and the test has passed > > ??????????????? // The debugd remains running, we have to kill it > > ??????????????? debugd.destroy(); > > ????????? ??????debugd.waitFor(); > > *??????????????? if (!testResult) {* > > *??????????????????? throw new RuntimeException("Expected message \"" +* > > *??????????????????????????? RMI_CONNECTOR_IS_BOUND + rmiPort + "\" is not found in the output.");* > > *??????????????? }* > > ??????? ????} while (portInUse); // Repeat the test if the port is already in use > > Is this really intended ?? from the comments in the test I had the impression that in case of?? ?port in use??? / ?address already in use??? the test should be repeated ? > > Otherwise if this is intended, should we flag the test? with? @key ?intermittent? ? > > Thanks and best regards, Matthias > From suenaga at oss.nttdata.com Fri Dec 31 13:42:41 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 31 Dec 2021 22:42:41 +0900 Subject: OpenJDK SADebugDTest.java test : handling of "Address already in use" In-Reply-To: <1ad4d98c-b779-5402-8a6a-387996f8984e@oss.nttdata.com> References: <1ad4d98c-b779-5402-8a6a-387996f8984e@oss.nttdata.com> Message-ID: <579c774d38b04f4760cd853b9d746723@oss.nttdata.com> I've sent PR for this problem: https://github.com/openjdk/jdk/pull/6941 > `testResult` and `portInUse` are important variables in this logic, > however they are overwritten in lambda expression - they won't affect > to the caller. > (I wonder why the test can compile without any error...) They are class member, so they work fine. However it is a little confusing, so I refactored it in this PR. Thanks, Yasumasa 2021-12-31 18:49 ? Yasumasa Suenaga ????????: > Hi Matthias, > > I think SADebugDTest.java wouldn't work that we expect. > > ``` > 114 Process debugd = startProcess("debugd", pb, null, > 115 l -> { > 116 if (!useRmiPort && l.contains(GOLDEN)) > { > 117 testResult = true; > 118 } else if (useRmiPort && > l.contains(RMI_CONNECTOR_IS_BOUND + finalRmiPort)) { > 119 testResult = true; > 120 } else if > (l.contains(ADDRESS_ALREADY_IN_USE)) { > 121 portInUse = true; > 122 } > 123 return (l.contains(GOLDEN) || > portInUse); > 124 }, 20, TimeUnit.SECONDS); > ``` > > `testResult` and `portInUse` are important variables in this logic, > however they are overwritten in lambda expression - they won't affect > to the caller. > (I wonder why the test can compile without any error...) > > Anyway, we should fix it. I will fix and will send PR. > > > Thanks, > > Yasumasa > > > On 2021/12/30 17:29, Baesken, Matthias wrote: >> Hello, I have a question regarding the test? SADebugDTest.java . >> >> The test >> >> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java >> >> >> seems to handle already cases where ?Address already in use? is found >> in the output (see line 120 ). >> >> However in our nightly test,? the SADebugDTest.java?? fails with this >> output : >> >> LingeredApp stdout: []; >> >> LingeredApp stderr: [] >> >> LingeredApp exitValue = 0 >> >> ----------System.err:(17/1318)---------- >> >> [debugd] Attaching to process ID 372 and starting RMI services, please >> wait... >> >> [debugd] Error attaching to process or starting server: >> sun.jvm.hotspot.debugger.DebuggerException: >> java.rmi.server.ExportException: Port already in use: 39399; nested >> exception is: >> >> *[debugd] java.net.BindException: Address already in use* >> >> [debugd] at >> jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:384) >> >> java.lang.RuntimeException: Expected message "RMI connector is bound >> to port 39399" is not found in the output. >> >> ? at SADebugDTest.testWithPid(SADebugDTest.java:132) >> >> ? at SADebugDTest.runTests(SADebugDTest.java:68) >> >> ? at SADebugDTest.main(SADebugDTest.java:60) >> >> ? at >> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> >> ? at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> >> ? at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> >> ? at java.base/java.lang.Thread.run(Thread.java:833) >> >> JavaTest Message: Test threw exception: java.lang.RuntimeException: >> Expected message "RMI connector is bound to port 39399" is not found >> in the output. >> >> JavaTest Message: shutting down test >> >> Looks like? the *ADDRESS_ALREADY_IN_USE *string is checked below;? >> however later in the coding? portInUse? is not checked but? the >> RuntimeException ??Expected message . . .?? is thrown : >> >> ??????????????? Process debugd = startProcess("debugd", pb, null, >> >> ??????????????????????? l -> { >> >> ??????????????????????????? if (!useRmiPort && l.contains(GOLDEN)) { >> >> ??????????????????????????????? testResult = true; >> >> ??????????????????????????? } else if (useRmiPort && >> l.contains(RMI_CONNECTOR_IS_BOUND + finalRmiPort)) { >> >> ????????????????????????????? ??testResult = true; >> >> *??????????????????????????? } else if >> (l.contains(ADDRESS_ALREADY_IN_USE)) {* >> >> *??????????????????????????????? portInUse = true;* >> >> ??????????????????????????? } >> >> ??????????????????????????? return (l.contains(GOLDEN) || portInUse); >> >> ??????? ????????????????}, 20, TimeUnit.SECONDS); >> >> ??????????????? // If we are here, this means we have received the >> golden line and the test has passed >> >> ??????????????? // The debugd remains running, we have to kill it >> >> ??????????????? debugd.destroy(); >> >> ????????? ??????debugd.waitFor(); >> >> *??????????????? if (!testResult) {* >> >> *??????????????????? throw new RuntimeException("Expected message \"" >> +* >> >> *??????????????????????????? RMI_CONNECTOR_IS_BOUND + rmiPort + "\" is >> not found in the output.");* >> >> *??????????????? }* >> >> ??????? ????} while (portInUse); // Repeat the test if the port is >> already in use >> >> Is this really intended ?? from the comments in the test I had the >> impression that in case of?? ?port in use??? / ?address already in >> use??? the test should be repeated ? >> >> Otherwise if this is intended, should we flag the test? with? @key >> ?intermittent? ? >> >> Thanks and best regards, Matthias >> From ysuenaga at openjdk.java.net Fri Dec 31 13:48:26 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 31 Dec 2021 13:48:26 GMT Subject: RFR: 8279351: [TESTBUG] SADebugDTest.java does not handle "Address already in use" error Message-ID: We expect SADebugDTest.java will retly the test when it encounters "Address already in use" error. However RuntimeException is thrown when the error happens. So I fixed it with some refactoring in this PR. Key change is the condition in L129. Please see serviceability-dev post for details. https://mail.openjdk.java.net/pipermail/serviceability-dev/2021-December/040453.html ------------- Commit messages: - 8279351: [TESTBUG] SADebugDTest.java does not handle "Address already in use" error Changes: https://git.openjdk.java.net/jdk/pull/6941/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6941&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279351 Stats: 28 lines in 1 file changed: 11 ins; 13 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6941.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6941/head:pull/6941 PR: https://git.openjdk.java.net/jdk/pull/6941