RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v2]

[Tom Rodriguez]

On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309.  In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure.  Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt.
>
> Tom Rodriguez 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 three additional commits since the last revision:
> 
>  - adjust OOMEInStampedLock.java too
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler

I'm not sure there are a lot of great alternatives.  There's no easy global solution to the problem of EA being unable to materialize values during deopt so these kinds of problems crop up in tests, particularly with Xcomp.  So the choices boil down to don't run it under Xcomp with Graal or work around it.  Something about the structure of this test reliably causes a unreached deopt in this code path and that seems to caused of some relatively recent random JDK change as this had been passing previously.

Modifying the test in this way seem like a pragmatic way of dealing with it.  The main is effectively the harness, so the change has no effect on the validity of the test itself.  We can always revisit this if it crop up again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2605220919