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