After the addition of the JFR ThreadSleep event, the Thread.sleep(millis) method may allocate the new objects so code that uses Thread.sleep when attempting to continue after OOME may fail, e.g.
try {
//Try to do some heavyweight work
}
} catch (OutOfMemoryError e) {
}
// Give the GC a chance at that weakref/softred in case of slow systems
Thread.sleep(2000);
// then repeat
I think it was not intentional behaviour change, can we restore the old behaviour somehow? or the code should be updated to be ready of OOM from this method?
try {
//Try to do some heavyweight work
}
} catch (OutOfMemoryError e) {
}
// Give the GC a chance at that weakref/softred in case of slow systems
Thread.sleep(2000);
// then repeat
I think it was not intentional behaviour change, can we restore the old behaviour somehow? or the code should be updated to be ready of OOM from this method?
- duplicates
-
JDK-8335734 Test sun/java2d/Disposer/TestDisposerRace.java fails with OOME in unexpected location
- Closed
- relates to
-
JDK-8335734 Test sun/java2d/Disposer/TestDisposerRace.java fails with OOME in unexpected location
- Closed
-
JDK-8340072 Test vmTestbase/nsk/monitoring/stress/thread/strace009/TestDescription.java fails after JDK-8299419
- Closed
- links to
-
Commit(master) openjdk/jdk/b0cff6b5
-
Review(master) openjdk/jdk/20923