On Tue, 18 Mar 2025 17:10:58 GMT, Alexander Zuev <kiz...@openjdk.org> wrote:
> 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. Sounds like (pun intended) my example did not land :) Let's continue with my example. In that example, I think we established the current check would throw OOME when sound bank in >57M. Suppose the bank was 128M. In my example, there is 2G of floating garbage in the heap. Once GC hits, it is likely a lot of that floating garbage gets cleaned up. Suppose GC managed to clean up 1G. Cool, we need more memory -- "large pool of memory comparable to the amount allocated to the sound bank itself" -- so another 128M? Now the heap has 1024M+2*128M = 1280M out of total 2048M. Very comfortable heap conditions! But instead, we are throwing OOME. I think this behavior goes against common sense. Note that arbitrarily lazy GC may end up pushing the checked limit arbitrarily low, and the code would start throwing OOME on very small sound banks, AFAICS. In other words, this reliability check, as written now, is actively hostile to reliability! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2734139561
