Posted by r.jaoui on Mar 25, 2021; 5:50pm
URL: https://forum.jogamp.org/JOGL-Texture-Memory-Management-tp4041055p4041060.html

As a closure to this post, I've found the solution :

I tried with a manual close function (without the GC-based finalize() method) and using the initally generated IntBuffer as the glDeleteTextures target… And I have no leak whatsoever and the memory consumption seems constant (higher at higher FPS, which can be expected since textures are loaded and unloaded so fast that memory has more “overlap”).

So I guess that the issue was that the GC was so slow to call the finalize method that at this point a lot of textures weren’t discarded and it looked like a leak… where it was just that tens of textures were not used and deleted too late by the GC (I bencharked a single of these textures to be about 30MB, so even as few as 30 simultaneous would be around 1GB, and given that the GC’s destructions could sometimes be of 50 at a time… A few GB is to be expected).

To be fair, I actually don’t even think that the glDeleteTextures call worked since when replacing the IntBuffer in finalize() with the original one, I got this error (I’m still curious on what it means) :

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000715475d9, pid=28448, tid=0x0000000000006d84
#
# JRE version: Java(TM) SE Runtime Environment (8.0_151-b12) (build 1.8.0_151-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.151-b12 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [nvoglv64.DLL+0xa175d9]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# D:\Programmation\Workspaces\Workspace 8 - Processing\SGLRL\hs_err_pid28448.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

But then, if I replace the finalize() call with a close() function, my memory consumption doesn’t get above a few hundred MB (expected for such a large number of images) and above all, DOESN’T INCRESE (which was the case even with a close() function if the glDeleteTextures() target wasn’t the actual initial IntBuffer).

Thanks to you all :)