On Fri, 6 Nov 2026 19:12:27 GMT, Vladimir Kozlov <[email protected]> wrote:
>> The test >> [java/util/concurrent/locks/Lock/OOMEInAQS.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java) >> timed out when run with "-XX:-TieredCompilation >> -XX:+UnlockDiagnosticVMOptions -XX:CompileThresholdScaling=0.01" flags. >> >> The test checks that AQS-based locks, conditions, and `CountDownLatches` do >> not fail when encountering OOME. It intentionally fills Java heap to get >> OOME. >> >> With `-XX:CompileThresholdScaling=0.01` C2 compiles test's code and >> scalarize new `ConditionNode` object in >> `AbstractQueuedSynchronizer::newConditionNode()` using >> `ReduceAllocationMerges` optimization. >> >> One of test's worker threads executes compiled code and hit uncommon trap. >> During deoptimization scalarized object rematerialization failed (heap is >> full) and VM throws OOME. The affected inlined frames are popped because we >> can't execute them without materialized objects (see >> [InterpreterRuntime::exception_handler_for_exception()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L522)). >> As result, the inlined OOME handler is bypassed. >> >> The test worker thread which hit deoptimization exits through "catch >> (Throwable ex)" path without notifying other worker threads which hang on >> "cond.await()" and we got timeout. >> >> I suggest using an allocation's JVMstate information to walk through inlined >> frames and check for OOME handlers. Don't eliminate the allocation If we >> find such handler. Narrow this condition only for `ReduceAllocationMerges` >> optimization for this fix. I concern that general solution may introduce a >> performance regression. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Vladimir Kozlov has updated the pull request incrementally with one > additional commit since the last revision: > > Add diagnostic run to StressStackOverflow.java test No need reviews from `build` and `core-libs` [Add diagnostic run to StressStackOverflow.java test](https://github.com/openjdk/jdk/pull/33197/commits/b7e22139e1a4c72276182df857f9a811f0b139f7) changes are temporary - they will not be part of final changes (I may file a separate bug and put the test to problem list to address the issue later). ------------- PR Comment: https://git.openjdk.org/jdk/pull/33197#issuecomment-6694422864
