RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon [v2]

David Holmes dholmes at openjdk.org
Tue Feb 10 04:50:12 UTC 2026


On Tue, 10 Feb 2026 03:26:27 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR merge test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java to test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and make the vmTestbase tests use the ClassUnloadCommon.
>> 
>> The core method in test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java is `boolean unloadClass()`, and the core method in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java is `Set<String> triggerUnloading(List<String> classNames)`, it's not easy to combile these two methods to one. So I keep all these two methods.
>> 
>> Additional testing:
>> 
>> - [x] Full jtreg tests include vmTestbase
>
> SendaoYan 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 31 additional commits since the last revision:
> 
>  - Fix missed attempt++
>  - Add "import jdk.test.lib.classloader.CustomClassLoader;" for vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/TestDescription.java etc..
>  - Adapt DEFAULT_BREAKPOINT_LINE from 63 to 65, since two lines added to test/hotspot/jtreg/vmTestbase/nsk/share/jpda/AbstractDebuggeeTest.java
>  - Add "import jdk.test.lib.classloader.ClassFileFinder"
>  - fix vmTestbase/nsk/jdi/Scenarios/invokeMethod/redefineclasses001/TestDescription.java fails "cannot find symbol ClassFileFind"
>  - sed -i "s|import nsk.share.CustomClassLoader;|import jdk.test.lib.classloader.CustomClassLoader;|" `grep nsk.share.CustomClassLoader test/ -rnl `
>  - Fix test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java fails "cannot find user-defined classloader loaded: nsk.share.CustomClassLoader"
>  - Fix javac error: "AbstractDebuggeeTest.java:103: error: cannot find symbol"
>  - Merge branch 'openjdk:master' into jbs8376023
>  - Fix comment in test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/2fd75594...bff25ebf

I think the motivation was to avoid needing to (but forgetting to) update both chunks of unloading code at the same time. But we certainly do want any dependencies into the vmTestBase sources.

I wonder whether the vmTestbase version could just delegate the actual functionality to the test library version? Though we would still need to update all the vmTestBase tests that use it to ensure it gets built and is accessible at runtime.

I'm really not sure this is actually worth the upheaval.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29545#issuecomment-3875308504


More information about the serviceability-dev mailing list