JDK-8227309 : Handle OOM when rematerializing objects less surprising
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u40,11,12,13,14
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-07-05
  • Updated: 2024-10-23
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.
Other
tbdUnresolved
Related Reports
Duplicate :  
JDK-8270010 - Handling of failed reallocation of scalar-replaced objects skips some exception handlers
Relates :  
JDK-8226536 - Catch OOM from deopt that fails rematerializing objects
Relates :  
JDK-8320205 - some GC stress tests fail due to OOM in EA materialization
Relates :  
JDK-8273095 - vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java fails with "wrong OOME"
Relates :  
JDK-8066400 - Reserve memory for OOME exception processing during deoptimization
Relates :  
JDK-8289764 - gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"
Relates :  
JDK-8270010 - Handling of failed reallocation of scalar-replaced objects skips some exception handlers
Relates :  
JDK-8269849 - vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"
Description
In JDK-8226536 we did a test fix to a test that provokes OOM and runs into problem when failing to rematerialize scalar replaced objects in deoptimization. 

That bug report contains reproducers and thoughts. Some of the issues encountered:
* The OOM is thrown from an unexpected place
* The finally block is not run

In the future with value types this situation might become more common. We need to decide how we want to handle this.
Comments
[~dnsimon] No, not that I'm aware of.
23-10-2024
[~thartmann] have there been further thoughts on this in the context of Valhalla?
22-10-2024
Fixing this should address JDK-8270010 as well.
01-03-2022
Deferred to JDK 15 for now due to complexity.
08-11-2019
I would say: ILW = Incorrect execution or OOM from unexpected location, when failing to rematerialize scalar replaced objects due to OOM, disable scalar replacement (-XX:-EliminateAllocations) = HLM = P3
08-07-2019