[9] RFR for JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads'
Mikael Gerdin
mikael.gerdin at oracle.com
Mon Oct 10 13:59:41 UTC 2016
Hi,
On 2016-10-10 09:24, Shafi Ahmad wrote:
> Hi All,
>
> Please review the simple change for the fix of bug '' JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads'.
>
> Summary:
> In the current implementation there are few scenarios where we are not obeying the jvm option -XX:+CrashOnOutOfMemoryError.
> While I was analysis this issue I found there are two jvm state where OOM can happen:
> 1. OOM during VM initialization - as per our internal discussion for this case it is not worth for dumping core file, so this is left as it is.
> 2. OOM once VM is initialized - For this scenario most of the place code is already added but few place corresponding code changes are missing so this change covers it.
>
> Webrev link: http://cr.openjdk.java.net/~shshahma/8155004/webrev.00/
There is a lot of confusion in the VM code with the term "out of memory
error".
In some places it refers to code throwing a java.lang.OutOfMemoryError
and expecting running java code to be able to potentially catch that
Error and continue running.
In other places, such as callers of report_vm_out_of_memory, the
situation is much more dire and the calling thread may not even be a
JavaThread and as such cannot "throw" an exception.
report_vm_out_of_memory is only invoked through the macro
vm_exit_out_of_memory, which of course implies that the condition is
fatal and we are about to terminate the JVM process altogether.
I think that it's incorrect to call code related to
java.lang.OutOfMemoryError in report_vm_out_of_memory since the
condition may not even be correlated with Java level application behavior.
/Mikael
> Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8155004
>
> Testing: jprt and jtreg (on Linux x86_64)
>
> Regards,
> Shafi
>
More information about the hotspot-runtime-dev
mailing list