On Mon, 3 Mar 2025 17:51:36 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> Well, it does contain a valid MIDI sequence that produces 1.9GB sound file - >> you can try to render it with any MIDI sequencer and will get the same >> result - the uncompressed WAV file generated with Apple GarageBand is about >> 2.1GB. That's just how MIDI work. > > If the data is correct then you do not need to add any additional checks in > front, just proceed it as is and catch OOM. similar to > [this](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388#diff-b92a36346bec4c6f7d5e8921bd69b038e0932f116d627bb4f6b514e670e1fccdR1035). That's actually a very bad idea for two reasons: 1. It will consume a lot of resources loading and rendering the sound bank impacting background task that might fail because they do not have enough memory - and that's while we know upfront that we will not be able to finish with the rendering process. 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? 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1977961866
