RFR: 8319932: [JVMCI] class unloading related tests can fail on libgraal

Doug Simon dnsimon at openjdk.org
Thu Feb 29 08:22:53 UTC 2024


On Thu, 29 Feb 2024 06:01:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 131:
>> 
>>> 129:         int attempt = 0;
>>> 130:         while (!loadedClasses.isEmpty() && attempt < 20) {
>>> 131:             ClassUnloadCommon.triggerUnloading();
>> 
>> This sort of re-try logic is what is supposed to be encapsulated by `ClassUnloadCommon.triggerUnloading`, or perhaps more accurately the underlying `WhiteBox.fullGC()`. Individual tests should not have to know about such things.
>
> Is there a way to do something like `WhiteBox.waitForCompilationToComplete()` prior to calling `fullGC()`?

All I see is `WhiteBox.enqueueMethodForCompilation` which will only wait for a compilation when `BackgroundCompilation` is `false`. Even then, which compilation(s) should be waited for?

We also have the issue that libgraal is not always as eager to clear object handles (see [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)), especially in `-Xcomp` mode and the retry loop helps in that situation as well.
If this retry logic should be in `ClassUnloadCommon.triggerUnloading`, then we'd need a second version of that method that takes a set of classes that are expected to be unloaded (e.g. `ClassUnloadCommon.triggerUnloading(String... namesOfClassesToBeUnloaded)`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18044#discussion_r1507182504


More information about the hotspot-runtime-dev mailing list