On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez <ne...@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 Changing the test this way does not sit well with me either. This adjustment to the test is far too intricately entwined with the implementation details of a particular JIT. I'm much more inclined to exclude Xcomp mode for OOME tests; or perhaps just disable EA (if Graal supports that) so we get most Xcomp coverage whilst side-stepping the EA issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2606338305
