JDK-8026331 : hs_err improvement: Print if we have seen any OutOfMemoryErrors or StackOverflowErrors
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7,8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-10-11
  • Updated: 2019-01-14
  • Resolved: 2015-06-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u192Fixed 9 b72Fixed
Related Reports
Relates :  
A very useful piece of information in JRockit dump files was a counter of OutOfMemoryErrors and StackOverflowErrors. Even if we should always try to handle these errors correctly, there are a lot of corner cases. If a customer sees hundreds of OOMs before crashing, it isn't unreasonable that this is the root cause. Even if we still want to fix the crash, the customer can start with fixing their OOM issue.
We can count Java heap OOMs and StackOverflowErrors. This may add overhead to throwing exceptions. We abort fairly quickly when there is a native heap out of memory error (or return NULL from the native heap allocation functions) so there's no way to count those. The hs_err message is pretty specific for native out of memory errors.

After JDK-8044594, there is an mbean SystemResourcePressureMXBean that has the attribute MemoryPressure. This is 0 by default, but can be set to a value between 0 and 10. Setting this value indicates that native memory is getting low. If this value has ever been set to a value other than 0, we could print this here as "Maximum MemoryPressure"

Once JDK-8026324 is fixed, we should make sure this information is in the summary