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

[Alexander Zuev]

On Wed, 5 Mar 2025 21:34:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8350813' of https://github.com/azuev-java/jdk into JDK-8350813
>  - Add a treshold of 90% to avoid OOME because of the additional buffers needed to process sound bank.

> * Throw OOME on > maxMemory, because there is no practical way GC would be able to satisfy the allocation.
> * Proceed to allocate otherwise, and let GC to either deal with it -- by triggering cleanup -- or throw OOME to indicate a failure of doing so.

The idea of the fix is strictly specific to the code in the sound bank loader. It takes into account that
1. To avoid huge memory allocations in one go the code grabs memory incrementally as it renders the audio data
2. It is not practical to load sound bank that requires a lot of memory to be freed by GC because what are you going to do next? To use loaded sound bank to render MIDI you will need another large pool of memory comparable to the amount allocated to the sound bank itself so 90% of the available memory is very conservative.

Bottom line - i do not think that catching OOME and re-throwing it as a checked exception down to the client code is a good idea and gradually allocating more than 90% of currently available memory - potentially suffocating other threads - i would say not the greatest idea either. In this particular scenario. Not a universal solution but for this specific application i would rather do that check before i go into the gluttony mode.

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

PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2734075145