Openj9: Support the `-XX:+ExitOnOutOfMemoryError` option

[DanHeidinga]

-XX:+ExitOnOutOfMemoryError on Hotspot just terminates without creating any diagnostic files. If you add options to create diagnostic files like -XX:+HeapDumpOnOutOfMemoryError the files are created before terminating.

The implementation would be to exit on any java.lang.OutOfMemoryError whether thrown by the VM or by user code.

The "exit check" would have to be after the hook that generates the diagnostic files as the OpenJ9 equivalent of -XX:+HeapDumpOnOutOfMemoryError is the default

[gacholio]

Might this be better done as an -Xdump option, where it could use the existing filter mechanisms to allow any exception, etc?

[charliegracie]

Supporting the exact same option as HotSpot will help with transitioning to OpenJ9. That being said a more generic solution would be great. This option could just take advantage of the generic solution.

[DanHeidinga]

We have support for -Xdump:tool:events=throw+systhrow,filter=java/lang/OutOfMemoryError,exec="kill -9 %pid" which effectively does the same thing in a less straightforward way.

Unfortunately, it doesn't work in Docker when the JVM ends running as pid 1.

I'm fine with adding a new "exit" action to the Xdump so it can be used by other -Xdump options. As @charliegracie says, adding the -XX:+ExitOnOutOfMemoryError option as a alias aids migration and is worth doing.

[pmhayward]

Please add doc:externals label if this is to be implemented

[theresa-m]

Does this sound like the right approach?

1. create a new dump agent that just exits the vm when triggered without dumping
   
   
   
   • something like -Xdump:exit:events=throw+systhrow,filter=java/lang/OutOfMemoryError
   
   
   • triggered agent will call vm->internalVMFunctions->exitJavaVM() to ensure vm will exit avoiding the linux docker issue where its not possible to kill pid 1
   
   
2. create an alias between -XX:+-ExitOnOutOfMemoryError and -Xdump:exit:events=throw+systhrow,filter=java/lang/OutOfMemoryError

[gacholio]

I like the option, but I'm not sure that calling exitJavaVM will be reliable (i.e. could hang).

Also, I think ordering may be important here, e.g. I'd like to dump various cores on OOM, and then exit.

[theresa-m]

Is there a way to guarantee that the jvm won't hang?

[gacholio]

What does Oracle do in this case? If they don't attempt to run the java shutdown hooks, then I suppose we could just hard exit.