I have a similar solution using weak references to GPU resources, but as you highlight there is no guarantee the GC will ever clean them up. Unfortunately you still have manage those resources yourself, the focus of the code is purely on detecting orphaned VBOs, textures, etc. as a diagnostic, either periodically or as a dump when the app is closed down.

The only guarantee the JRE makes on this matter is that this will happen before Java runs out of heap-space

I already mentioned that several times here and on Ardor3D's forum, it's up to you to manage the native memory, you can run out of memory on the native heap if there is still enough memory on the Java heap. I quoted a documentation of IBM about that several months ago.

Quote

I solved the problem by explicitly removing buffers that I know are no longer required from the GPU

I have done the same in TUER about a month, I call glDeleteBuffers and I release the native memory of the direct NIO buffer.

Quote

you shouldn’t try to to be too smart around resources allocated out of sight of the garbage collector

Actually, you can't be smart, you have to track those resources by yourself.

I did see that post you mentioned, but I forgot all about it. A pity, for it would have saved me some time :-)

Minor difference is that I ran into problems with GPU memory instead of native buffers, but the cause is exactly the same. I was wondering if I should post on the Ardor forum to alert people about the problem, but now I see that you have already done so.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org