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

[Thomas Stuefe]

On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Greetings,
> 
> this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches.
> 
> The fix is very straightforward. 
> 
> One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. 
> 
> If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread?
> 
> - No if I take the option name literally, since there is no OOM involved
> - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit.
> 
> Thanks, Thomas

I would fix it because its a well known and documented way to handle OOMs in a VM. In fact its much better known than AbortVMOnException, and has been around for much longer. People use these switches, expect them to work, but they don't.

Other reasons include:
- maybe the customer does not want to crash but just a clean exit
- maybe the customer wants to have a heap dump to take a look at who created that many java threads
- Fix is really really simple

Thanks, Thomas

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

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