On Wed, 5 Mar 2025 21:34:09 GMT, Alexander Zuev <kiz...@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. I emphasize the problem is with relying on `freeMemory`. That thing is not trustworthy to make the call you want to make. Only GC knows how much memory there is _actually free_, and it often knows only after attempting a GC cycle. If you want to get some headroom for both sound bank allocation and the subsequent rendering, then maybe the limit should be `maxMemory / <const>`, where divisor is some small integer. But `freeMemory` should not be in the equation if you want reliability, AFAIU. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2734159467
