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

[Shafi Ahmad]

Hi David,

Thanks for the clarification. I will send the updated webrev.

Regards,
Shafi

> -----Original Message-----
> From: David Holmes
> Sent: Friday, October 14, 2016 12:02 PM
> To: Shafi Ahmad; Mikael Gerdin; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: [9] RFR for JDK-8155004: CrashOnOutOfMemoryError doesn't
> work for OOM caused by inability to create threads'
> 
> Hi Shafi,
> 
> I stand by my previous comment - in the context of this bug, in relation to
> failure to create a native thread "A call to report_java_out_of_memory
> should only be made on a code path that will throw an OOME."
> 
> Does this mean we have all OOM (not OOME)** situations covered? Nope.
> But HeapDumpOnOutOfMemoryError and CrashOnOutOfMemoryError
> seem specific to OutOfMemoryError to me - and not that useful for dealing
> with the JNI leak you describe.
> 
> Feel free to file a RFE to look into more elaborate/extensive OOM handling.
> I'm not sure if NMT hooks into JNI.
> 
> Thanks,
> David
> 
> 
> ** OOM - out-of-memory
>     OOME - OutOfMemoryError - a Java exception thrown in response to a
> detected OOM condition
> 
> On 14/10/2016 3:28 PM, Shafi Ahmad wrote:
> > Hi,
> >
> > May I get some comment on this.
> >
> > Regards,
> > Shafi
> >
> >> -----Original Message-----
> >> From: Shafi Ahmad
> >> Sent: Wednesday, October 12, 2016 12:42 PM
> >> To: Mikael Gerdin; hotspot-runtime-dev at openjdk.java.net
> >> Cc: David Holmes
> >> Subject: RE: [9] RFR for JDK-8155004: CrashOnOutOfMemoryError doesn't
> >> work for OOM caused by inability to create threads'
> >>
> >> Hi Mikael,
> >>
> >> Thanks for reviewing it.
> >>
> >> Once VM is initialized, following are two OOME scenarios:
> >>  1) OOME due to unavailability of java memory [Mainly due to java
> >> application].
> >>  2) OOME due to unavailability of native memory.
> >>
> >> Please correct me if I am wrong, for 1) java.lang.OutOfMemoryError is
> >> correct.
> >>
> >> Consider the following scenarios:
> >> 1) Let there is java application which uses JNI code and inside JNI
> >> code there is native memory allocation/free and we hit OOME.
> >> 2) Let there is java application which uses JNI code and inside JNI
> >> code there is memory leak error and due to this OOME situation occurs.
> >> 3) We use jvm option Xms and  -Xmx in such a way that the available
> >> native memory is very less and VM hit OOME.
> >>
> >> I am not sure above scenario is feasible in JVM or not but if any of
> >> the above scenario is possible in VM then should we consider it as
> >> OOME due java application or not?
> >> I consider case 1) and 2) as OOME due to java application and added
> >> code for java.lang.OutOfMemoryError inside
> report_vm_out_of_memory.
> >>
> >> My  assumption of OOME once VM is initialized completely is due to
> >> java application[directly or indirectly] may not hold true always.
> >> -XX:+CrashOnOutOfMemoryError is mostly for debugging purpose so I
> >> added the related code change inside report_vm_out_of_memory.
> >> Yes, I must not use ' java.lang.OutOfMemoryError'  for such case.
> >>
> >> Please let me know whether I should remove the code change inside
> >> report_vm_out_of_memory or keep it by adding appropriate reason of
> >> OutOfMemoryError.
> >>
> >> Regards,
> >> Shafi
> >>
> >>> -----Original Message-----
> >>> From: Mikael Gerdin
> >>> Sent: Monday, October 10, 2016 7:30 PM
> >>> To: Shafi Ahmad; hotspot-runtime-dev at openjdk.java.net
> >>> Subject: Re: [9] RFR for JDK-8155004: CrashOnOutOfMemoryError
> >>> doesn't work for OOM caused by inability to create threads'
> >>>
> >>> 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
> >>>>