RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can cause OutOfMemoryError [v3]

[Sergey Bylokhov]

On Mon, 3 Mar 2025 18:11:37 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>2. It is not advised to continue normal operation after OOME is caught, because at this moment VM might not work reliably unless we can guarantee that memory can be immediately released. For example in the code above we are trying to re-throw OOME as a checked exception - but if we do not have enough heap to instantiate a new IOException - then what? 

Then an OOM will be thrown, signaling to the application that it is not possible to proceed?

>What if some background task already failed because it could not initialize its inner classes? What if that background task is GC? It is commonly advised to catch OOME only as a "fail gracefully" scenario and be ready with pre-initialized output classes to save current state because you might not have enough heap to initialize the emergency shutdown procedure.

The current patch will not solve any of these issues, as the check in advance may pass while the code still fails producing an unexpected exception in the application. The try/catch block, at the very least, provides an opportunity for the application to catch the expected IOException instead of fatal OOM and retry or skip this file. That is exact reason why the try/catch was added [here](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388#diff-b92a36346bec4c6f7d5e8921bd69b038e0932f116d627bb4f6b514e670e1fccdR1035)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1978013315