RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot

David Holmes david.holmes at oracle.com
Thu Nov 26 05:43:36 UTC 2015


Hi,

On 25/11/2015 10:40 PM, cheleswer sahu wrote:
> Hi,
>
> Please review the code changes for
> "https://bugs.openjdk.java.net/browse/JDK-8138745".
> Web review link:
> <http://cr.openjdk.java.net/%7Ekevinw/8138745/webrev.00/>http://cr.openjdk.java.net/~kevinw/8138745/webrev.00/
>
> Enhancement Brief:
> ExitOnOutOfMemoryError: When user enable this option, the JVM exits on
> the first occurrence of an out-of-memory error. It can be used if user
> prefer restarting an instance of the JVM rather than handling out of
> memory errors.
>
> CrashOnOutOfMemoryError: If this option is enabled, when an
> out-of-memory error occurs, the JVM crashes and produces text and binary
> crash files.

The term "crash" is not very appropriate - crashes are bad things. Abort 
may have been a better choice.

> For more details please refer http://ccc.us.oracle.com/8138745

This is not accessible outside of Oracle.

A few minor comments:

src/share/vm/runtime/globals.hpp

+           "JVM crashes and produces text and binary crash files")

Terminology should be consistent with other options that control core 
dump. Should also say "on first occurrence of an out-of-memory error".

src/share/vm/utilities/debug.cpp:

  308     if (CrashOnOutOfMemoryError) {
  309       tty->print_cr("java.lang.OutOfMemoryError: %s", message);
  310       fatal("OutOfMemory encountered: %s", message);
  311     }

don't really need the tty->print when using the fatal. Though you may 
want to use the j.l.OOME form of the message for consistency. Might also 
be useful for both Crash and Exit to include in the logged messages the 
fact that these flags were involved - something like:

"Terminating due to java.lang.OutOfMemoryError: %s"
"Aborting due to java.lang.OutOfMemoryError: %s"

Thanks,
David
-----

>
> Regards,
> Cheleswer
>


More information about the serviceability-dev mailing list