On Mon, 1 Jun 2026 18:30:39 GMT, Quan Anh Mai <[email protected]> wrote:
>> Hi, >> >> When `StressReachabilityFences` is `true`, the compiler tries to insert a >> reachability fence for all incoming states of the compilation. This misses >> the fact that an incoming `InlineTypeNode` may be unbuffered, so this PR >> fixes that by not inserting reachability fences for incoming >> `InlineTypeNode`s. In addition, when `reachabilityFence` is called on an >> `InlineTypeNode`, we need to buffer it. >> >> Please take a look and leave your reviews, thanks a lot. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Quan Anh Mai has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains two additional > commits since the last revision: > > - Merge branch 'lworld' into reachabilityfence > - Fix ReachabilityFlagsTest src/hotspot/share/opto/library_call.cpp line 7886: > 7884: Node* referent = argument(0); > 7885: if (referent->is_InlineType()) { > 7886: referent = referent->as_InlineType()->buffer(this); Please explain. The test doesn't trigger this code, so how do we test it? I thought the whole point of reachabilityFence was to prevent a finalizer from running too early, but what does that even mean for an InlineType that might not be heap allocated? Wouldn't it be a no-op or even better, an error, like trying to synchronize on a value object? Or are we now saying that reachabilityFence on an inline type really means "do not scalarize, make sure finalizer gets run, but not until we get here"? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2496#discussion_r3338208626
