comparing memory consumption of jsr 231 1.0 with nightly build

OpenGL Development JOGL Development
#1

I just profiled my terrain engine because I noticed regular GCs. The result shows that not my engine caused the leak, jogl leaks memory!

I designed the engine to be 100% GC neutral at runtime (no object allocations/deallocations in the display() codepath) and it works quite well.
Here the test results:
jogl 1.0: no GCs at runtime
nightly build: collection every 3secs, around 5-10Mb collected each collection

I traced it down to com.sun.opengl.impl.GLBufferStateTracker. This class seems to track the states of all VBOs in a Integer Hashmap, which is a nice feature but the autoboxing hell for the VM/GC!
It would be really cool if we would have a switch to disable this memory profiling. (Or perhaps a MemProfiler wrapper like DebugGL)

Note: My engine uses a lot of VBOs
Note2: in near future (OpenGL 3.0) EVERYTHING will be (V)BO driven that would increase amount of glBindBuffer() calls

#2

Thanks for pointing this out and sorry for the trouble. The box() method in GLBufferStateTracker could be changed to maintain a cache of indices in similar fashion to what JDK 5 does internally (this code has to run on 1.4.2 as well). I’ve filed Issue 283 to track this.

#3

Thank you for the fast reply,

but why does JOGL track the state of Buffer Objects? Is it like a Exception throwing mechanism to force correct buffer usage (e.g. VBOs must be created before they are bound)?
(I’ m not talking of GLObjectTracker, there are several reasons to track the creation of GL Objects)

#4

It’s for security reasons. Each OpenGL API which is affected by the VBO or PBO extensions has two Java entry points generated for it. The VBO/PBO variant takes a long as argument which is the offset into the currently bound buffer object and may only be used when a buffer object is bound to the associated state. It would be a security hole, allowing people to specify arbitrary pointers into the address space, if you could call the version taking a long when a buffer object wasn’t bound. The GLBufferStateTracker enforces this as well as the opposite case (you can’t call the normal variant taking a New I/O Buffer when an OpenGL buffer object is bound).