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