On Wed, 9 Sep 2026 17:35:53 GMT, Coleen Phillimore <[email protected]> wrote:
>> Remove the upcall to addClass during class loading. The comment says it's >> only so GC can keep classes alive while the class loader is alive. We have >> other ways to do that. There were some JVMTI tests in the past that failed >> without this vector but today seems to be only one test. Maybe there's some >> code that has a dependency on this in heap walking. >> Tested tier1-6 >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > Fix wording in test. Not a special root reference. test/hotspot/jtreg/serviceability/HeapDump/ClassLoaderFieldsTest.java line 108: > 106: .addToolArg(Long.toString(theApp.getPid())) > 107: .addToolArg("GC.heap_dump") > 108: .addToolArg(dumpFile.getAbsolutePath()); Q: There can be a stale file by the path. Would it more safe to add the -overwrite option? test/hotspot/jtreg/serviceability/jvmti/FollowReferences/ClassLoader/ClassLoaderTest.java line 80: > 78: "FollowReferences starting at MyLoader reached > Test.class"); > 79: > 80: Asserts.assertTrue(targetKindIsOther(), "FollowReferences reports > Test.class as target kind OTHER"); Q: The asserts messages at lines 77, 80 sound like something positive. Would it better to say what test expectations do not match? test/hotspot/jtreg/serviceability/jvmti/FollowReferences/ClassLoader/libClassLoaderTest.cpp line 49: > 47: fflush(nullptr); > 48: return JNI_ERR; > 49: } The function `check_jvmti_error(jvmtiError err, const char* msg)` can be used from `jvmti_common.hpp` to check and report unexpected JVMTI error code. test/hotspot/jtreg/serviceability/jvmti/FollowReferences/ClassLoader/libClassLoaderTest.cpp line 71: > 69: target_seen = true; > 70: target_kind = kind; > 71: printf("Reached tagged Test.class, reference kind: %d\n", kind); The `jvmti_common.hpp` is already used by this test. So, the LOG macro can be used from there. It calls the `fflush()` automatically. This also applies to the lines: 36-37 and 46-47. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3975370641 PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3975383408 PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3975435657 PR Review Comment: https://git.openjdk.org/jdk/pull/32519#discussion_r3975416842
