JDK-8252189 : Clarify meaning of OOM texts for out-of-metaspace errors
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2020-08-22
  • Updated: 2021-02-23
  • Resolved: 2021-02-23
Related Reports
Relates :  
We throw an OOM in metaspace in two cases:

- when hitting CompressedClassSpaceSize (compressed-class-space-local reserve limit)
- when hitting MaxMetaspaceSize (global commit limit)

Text says "Out of Metaspace" resp. "Out of Compressed Class Space", depending on whether the allocation hitting the limit was from class space or not.

This is imprecise on multiple levels. 

The exception text is a bit misleading: naive interpretation would be "we hit the allocation limit for either class space or non-class space". But this is not what is currently implemented, nor can it be implemented, since non-class space has no limit (MaxMetaspaceSize is a global limit and limits compressed class space too).

We could change the behaviour such that the OOM text depends on which limit we did hit (regardless of the data type of the allocation). That would make more sense. But probably we should change the exception text too then, clearly stating the limit we hit.

Alternatively we could just keep the exception text more vague.

(This should be done after JEP387 hits mainline.)
After some consideration, I decided to leave it as it is. This is not precise but not easy to improve. For now: - If we hit MaxMetaspaceSize, it will be reported as OOM(Metaspace) - If we hit the limit of the class space, it will be reported as OOM(Compressed Class Space) - If we hit both, it will also be reported as OOM(Compressed Class Space)