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

Aleksey Shipilev shade at openjdk.org
Tue Mar 18 08:47:18 UTC 2025


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.

Looking at this from the GC perspective...

What I am concerned here is really hooking up to "observed" heap stats. It guesses what GC does, and it is not great for the non-core JDK code. Checking for `maxMemory` alone might be fine, it is straight up `CollectedHeap::max_capacity`, which is essentially Xmx. But checking on `freeMemory` is basically throwing ourselves at the mercy of GC doing prompt reclamations. I can envision the scenario where a super-lazy GC would delay the collection until the single-digit% of total memory is free, but the actual GC cycle would throw away a lot of garbage.

I.e. I think I can construct the case where:


maxMemory = 2048M (Xmx)
totalMemory = 2048M (actually expanded heap size)
freeMemory = 64M (lazy GC)
<floating garbage> = (2G - delta)


Then:


long maximumHeapSize = (long) ((Runtime.getRuntime().maxMemory() -
                    (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())) * 0.9); 


...computes to measly 57M (check my math) and thus throws OOME prematurely.

So, I would say:
 1. Throw OOME on > maxMemory, because there is no practical way GC would be able to satisfy the allocation.
 2. 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.

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

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


More information about the client-libs-dev mailing list