While profiling my allocation, it turned out a noticeable amount of objects were being created in calls to GLContext.makeCurrent() and GLCanvas.swapBuffers(). The objects created were ByteBuffers, LongBuffers, int[], Object[], com.sun.gluegen.runtime.StructAccessor, and com.sun.opengl.impl.JAWT_DrawingSurface64.
Are these allocations absolutely necessary (they seem to be made every frame)?
What’s worse, is that native buffers have at least the page-size byte count (4K) due to MappedByteBuffer alignment requirements.
So if you’re running at 100 FPS that would be 400K per new buffer, per second, probably using malloc(), which is slow.
Why would all native buffers have to meet that alignment requirement? That seems like a pretty bad design decision.
They just do.
Check either sun.misc.Unsafe or java.nio.Bits, IIRC. You can also see how native buffers are freed there (with soft references) and the code that throws the OOME (it’s just a counter)
In the internals the malloc looks something like this:
long bytes = ...;
long alloc_bytes = bytes + unsafe.pageSize();
long pointer = unsafe.malloc(alloc_bytes);
long buffer_base = (pointer + pageSize) - (pointer % pageSize);
And indeed, it’s a very high price to pay for MappedByteBuffers, especially as nobody (?) really uses them, because you can’t manually free them, causing memory problems very fast (direct memory is full quite fast, but GC won’t get called as heap memory isn’t growing much). See various RFEs.
Thanks, but now back to my main question, are these buffer and instance allocations necessary in makeCurrent() and swapBuffers(). If they are, I’d appreciate an explanation.
Assuming no response, I’ll probably just file a bug to the jogl developers.