MTLTexturePool GC algorithm is too simple, it is causing high allocation rates when resizing applications like J2Ddemo (lots of buffered or volatile image).
The current algorithm only uses a trigger at half the device recommended memory, but on my macbook M2 (16GB) it represents 11.3gb /2 = 5.5gb! Until this huge amount of GPU memory is allocated, no GC happens.
Moreover, textures are allocated by pool cells, but no extra space is allocated (exact size), so growing texture width or height requires new allocations!
This issue concerns MTLTexturePool's GC enhancements to be integrated first in jdk24 then proposed for the jbr21u branch.
The current algorithm only uses a trigger at half the device recommended memory, but on my macbook M2 (16GB) it represents 11.3gb /2 = 5.5gb! Until this huge amount of GPU memory is allocated, no GC happens.
Moreover, textures are allocated by pool cells, but no extra space is allocated (exact size), so growing texture width or height requires new allocations!
This issue concerns MTLTexturePool's GC enhancements to be integrated first in jdk24 then proposed for the jbr21u branch.