RFR: 8319932: [JVMCI] class unloading related tests can fail on libgraal
Doug Simon
dnsimon at openjdk.org
Thu Feb 29 13:26:43 UTC 2024
On Thu, 29 Feb 2024 12:56:22 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> 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)`).
>
> I think we would only need that second version because the first/existing one is unreliable! But given all these "incidental" things that can keep classes strongly reachable reliability may be a pipe-dream here. But even if it is just a better version I would still prefer to see this in the utility code than individual tests.
>
> BTW if this is a C1 issue any idea why we do not see it with C1 + C2 ?
Because `TypeProfileWidth` is only 2 when Graal is not being used so there's very little chance of `InitExceptionUnloadTest$SpecialException` being in a type profile (see PR description).
Just to be clear, you're saying I should add `ClassUnloadCommon.triggerUnloading(String... namesOfClassesToBeUnloaded)` in this PR?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18044#discussion_r1507568809
More information about the hotspot-runtime-dev
mailing list