RFR: 8321299: runtime/logging/ClassLoadUnloadTest.java doesn't reliably trigger class unloading

David Holmes dholmes at openjdk.org
Tue Mar 12 04:48:12 UTC 2024


On Mon, 11 Mar 2024 21:21:24 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> ClassLoadUnloadTest.java passes by accident because an unrelated LambdaForm is being unloaded. The test class, `test.Empty` should be loaded by a custom class loader and then subsequently unloaded, however this is not actually occurring due to the sub-process not receiving the class path. This patch modifies `ClassUnloadCommon`, so it may accept a string containing the classlist, and `ClassLoadUnloadTest.java` so it checks specifically for `test.Empty` to be unloaded. Verified with tier1-5 tests.

Seems to me that the real problem here is the use of `ProcessTools.createLimitedTestJavaProcessBuilder` as that prevents the launched VM from getting the properties that jtreg sets, and thus in turn the `newClassLoader()` code couldn't create the right classpath. If we explicitly set the `test.class.path` property for the exec'd VM then that should fix it.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18207#pullrequestreview-1930088861


More information about the hotspot-runtime-dev mailing list