On Tue, 18 Mar 2025 17:31:18 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
> Sounds like (pun intended) my example did not land :) No, i totally understand your point - it is quite possible that calculating currently available memory size might be detrimental because of the possibility that GC might free up that space when we actually request it - but this is not a critical functionality and the potential damage of suffocating VM with the repeated requests of +1M for potentially 4G sound bank - when we do know that we only have 3G of free memory - heavily outweighs the potential border-line case when we can load the sound bank - maybe - if GC will finds the resources but we were a little paranoid and throwing a checked exception that customer will take into account and the execution of the main program may continue. Conclusion: i know the risks and i am willing to take them, reliability concern is noted but it is the case where being cautious and a tiny bit paranoid makes more sense. Again, for this exact use case. Plus there is a workaround: user can just increase the maximum heap size if he finds that some specific sound bank causes this kind of a problem. If you find out that you need to generate 4G sound bank - add 4G of heap and you will be fine just fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23814#issuecomment-2734741051
