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

[David Holmes]

Hi Thomas,

On 21/04/2021 12:53 am, Thomas Stuefe wrote:
> 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
> 
> p.s. I do not understand your quotes around "bug", nor your hesitance to fix this. I have seen quite a number of desperate setups customers have around crashy or OOMy JVMs, to analyse and to restart quickly. Anything in that area we can do helps.

My hesitance is because the intent of these flags is to provide a 
response for Java heap exhaustion, not to provide a response to every 
place that java.lang.OutOfMemoryError may be thrown. You've picked this 
one case of native thread exhaustion to add-in but that just makes it 
inconsistent. Why should that case be handled and not all the others? It 
is unfortunate that there is more than one way to read OutOfMemoryError, 
but it should be read as out-of-Java-heap-memory-error. We have had bug 
reports when someone uses this flag and their code does "throw new 
OutOfMemoryError() and they want to know why the VM didn't crash!

I wouldn't object to a general broadening of what this flag applies to 
but I do object to cherry-picking a single case, resulting in the flag 
have no well-defined meaning at all.

And per your latest email perhaps we need new generic flags for 
resource-exhaustion.

Cheers,
David
-----

> One example, take a look at the way CloudFoundry handles OOMs in a JVM. They have a JVMTI agent hooked up to resource-exhausted, then attempt to run analysis code (written in Java too) to dump the heap. This is so fragile.

> 
> xxxOnOutOfMemoryError could really help in these scenarios, if it would function reliably.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3586
>