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