On Wed, 28 Oct 2026 14:47:32 GMT, Maurizio Cimadamore <[email protected]> wrote:
>> This test needs to conditionally hold inside a C2 compiled while loop. This >> is done by conditioning the loop on the value of an `AtomicBoolean`. In >> order for the loop body not to be compiled as an uncommon trap, which would >> result in the loop being deoptimized during the actual test when we want to >> hold inside the loop, we try to pollute the profile for the loop condition >> during warmup. This is currently done by switching the value of the >> `AtomicBoolean` rapidly in a different thread. >> >> However, in some rare cases the profile can observe only `false` values >> during the warmup, and so when the real test sets the condition to `true` >> the method containing the loop is deoptimized any way and the test fails >> because it sees no compiled method. >> >> This PR replaces the `AtomicBoolean` with a more specialized `Holder` that >> has a `shouldHold` method that returns a `boolean` value and then >> conditionally toggles its output after every call, instead of toggling the >> value from a different thread during warmup. This guarantees that we will >> see both `true` and `false` in the profile, and thus avoid the problematic >> uncommon trap. >> >> Testing: many runs of `test/jdk/:tier1` to reproduce the issue and confirm >> it disappears with this fix. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > test/jdk/java/foreign/TestSharedCloseDeopts.java line 176: > >> 174: assertEquals(deoptCountBeforeClose + (testCase.hasAccess() ? 1 >> : 0), deoptCountAfterClose); >> 175: >> 176: holder.toggleOutput(true); // release thread from loop > > does the comment re. release still applies? ah ok -- field is volatile, so probably yes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33352#discussion_r4402052569
