RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2]
David Holmes
dholmes at openjdk.org
Mon Jun 2 21:45:51 UTC 2025
On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:
>> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments.
>>
>> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest.
>>
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>
> Add WhiteBox back + typo
test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 56:
> 54: Class<?> c = cl.loadClass(className);
> 55: cl = null; c = null;
> 56: ClassUnloadCommon.triggerUnloading();
So the unloading is not part of this test? Are we just using the ClassUnloadCommon utility as a convenient way to get an additional classloader involved?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2122215783
More information about the hotspot-runtime-dev
mailing list