[lworld] RFR: 8367338: [lworld] compiler/gcbarriers/TestImplicitNullChecks.java fails
Roberto Castañeda Lozano
rcastanedalo at openjdk.org
Mon Sep 29 08:15:40 UTC 2025
On Wed, 24 Sep 2025 15:36:04 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:
> # Issue
> IR checks of `testCompareAndExchange`, `testCompareAndSwap` and `testGetAndSet` of `compiler/gcbarriers/TestImplicitNullChecks.java` fail because they expect no `NULL_CHECK` in the final code graph but it encounters a few in each test instead.
>
> # Cause
> The tests in question simply call 3 different `VarHandle` functions (one each) but these don't get inlined as intrinsics directly. They instead rely on inline methods (with some conditional statements) that eventually call a method that gets intrinsified. Unfortunately the compilation of some of the inlined code can result in null-checks after being compiled.
> For instance `testCompareAndExchange` inlines `Unsafe::compareAndExchangeReference`
> https://github.com/openjdk/valhalla/blob/1ecd2e95a158c80186d4334ca3f0673f660d5042/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L1723-L1742
> which calls `compareAndSetReference` or `compareAndExchangeReference` but `if (valueType.isValue() || isValueObject(expected))` adds a null-check for `valueType`.
> This happens only in Valhalla because of a Valhalla-specific value-type checks (see [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569)).
>
> # Fix
> The goal of the tests is to make sure that there are no null-checks with compare-and-exchange operations with ZGC and G1. Instead of relying on `VarHandle` compare-and-exchange-related methods we can use the equivalent `Unsafe` methods that are intrinsified directly.
>
> # Testing
> Tier 1-3+
`fVarHandle` is unused now and can be removed (together with all the code and imports around it).
-------------
PR Review: https://git.openjdk.org/valhalla/pull/1626#pullrequestreview-3278458832
More information about the valhalla-dev
mailing list