In JDK-8274072 we found that JDWP forcefully calls exit, which will run the destructors of global variables. This is problematic because other threads, like the GC threads, could still be using those objects.
We have a similar problem with -XX:+ExitOnOutOfMemoryError. It calls os::exit(), and causes the same problem.
I can reproduce this issue by adding this patch:
---
$ git diff
diff --git a/src/hotspot/share/gc/shared/gcTimer.cpp b/src/hotspot/share/gc/shared/gcTimer.cpp
index ca835e30ed3..150e03be0af 100644
--- a/src/hotspot/share/gc/shared/gcTimer.cpp
+++ b/src/hotspot/share/gc/shared/gcTimer.cpp
@@ -117,9 +117,16 @@ TimePartitions::TimePartitions() {
clear();
}
+#include "runtime/os.hpp"
+#include "runtime/globals.hpp"
TimePartitions::~TimePartitions() {
delete _phases;
_phases = NULL;
+ if (UseNewCode) {
+ fprintf(stderr, "~TimePartitions sleep\n");
+ os::naked_short_sleep(999);
+ fprintf(stderr, "~TimePartitions sleep done\n");
+ }
}
void TimePartitions::clear() {
---
and then running, say, SPECjbb2005:
java -XX:+UseZGC -XX:+UseNewCode -Xlog:gc -Xmx32m -Xms32m -XX:+ExitOnOutOfMemoryError -cp jbb.jar:check.jar spec.jbb.JBBmain
which results in:
Terminating due to java.lang.OutOfMemoryError: Java heap space
~TimePartitions sleep
...
# A fatal error has been detected by the Java Runtime Environment:
...
# V [libjvm.so+0xd06b08] GCTimer::register_gc_start(TimeInstant<CompositeCounterRepresentation, CompositeElapsedCounterSource> const&)+0x8