RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads

[Thomas Stuefe]

On Wed, 21 Apr 2021 06:10:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> > Its simply not implemented. The ...OnOutOfMemoryError handling needs to be added to places where OOM is thrown, and is missing from a couple of places.
> 
> Strictly speaking, we need to think about OOME from Java layer as well. For example, OOME would be thrown when direct buffer cannot allocate native memory (-XX:MaxDirectMemorySize). It is not caught by JVMTI ResourceExhausted event, however it might be important information to know system memory usage.
> 

Please open a new issue for that, we can then discuss this separately.

> I've found out similar issue on JFR, and I've posted #1403 , however it might not be accepted because C2 might eliminate throwing exceptions. IMHO *OnOutOfMemoryError, unified logging (-Xlog:exceptions), JVMTI event, JFR events should be hook all of OOMEs, they should be able to hook same source at least.

Fully agree. In fact, I think semantically binding the switches to *OutOfMemoryError* is a design flaw, since you can have any number of resource bottlenecks where one might wish to restart the VM but which do not result in a OOM in java; one example is the creation of native threads by the VM.

But that is a discussion for another day. We seem to have two opposite factions in this discussion. The "works as designed and leave it be" faction and the one wanting to cover as much resource exhaustion cases as possible by these switches. How do we proceed?

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

PR: https://git.openjdk.java.net/jdk/pull/3586