RFR: 8331208: Memory stress test that checks OutOfMemoryError stack trace fails

Doug Simon dnsimon at openjdk.org
Wed May 1 09:38:52 UTC 2024


On Wed, 1 May 2024 09:07:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think it was a mistake to make it conditional when RetryableAllocationMark was first introduced. The purpose of RAM was to only to resolve a correctness issue wrt to JVMTI (it was seeing the "same" exception being reported twice). The -XX actions do not change the semantics of the exception throwing so can be done unconditionally.
>
> But if this is a hidden/internal OOME then why would we treat it as a normal OOME and trigger the XX action? If the allocation routines returned null instead, we would never consider triggering the XX actions for OOME.

It depends on what the purpose of the `-XX` actions is. As far as I can tell, they are for understanding when and why the JVM hits a memory limit from an external perspective. For example, until something like https://bugs.openjdk.org/browse/JDK-8328639 exists, I don't think it would be easy to discover an OOME caused by the string constant resolution done by the JIT. But maybe that doesn't matter? I'm fine with keeping the XX actions conditional if you'd prefer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18925#discussion_r1586064382


More information about the hotspot-gc-dev mailing list