Direct ByteBuffer footprint

OpenGL Development JOGL Development
#1

First, I’m running on Solaris 9 but this looks like it will apply to at least some other platforms, e.g. Linux.

I just tried to move to using glDrawArrays() to render my geometry in order to see what speed inprovements I could find. As part of this
I changed the storage of each of my geometry ‘fragments’ to use its own direct ByteBuffer to store vertices, normals texcoords etc.

The result was a huge memory footprint for my process around 900MBytes or about 10x what I would expect. This is apparently caused by the JVM insisting on aligning direct ByteBuffers on page boundaries as documented here:

http://developer.java.sun.com/developer/bugParade/bugs/4820023.html

This makes it pretty well untenable to allocate a large quantity of ‘small’ direct ByteBuffers.

Setting up a smaller number of large buffers and handing out subsections dynamically doesn’t seem like a great solution, since it’ll make it very difficult to reclaim storage when I free a subsection.

So, would anyone, expecially the JOGL developers care to comment on this issue ?

Thanks
Rob

#2

OK - I just tried the test case in bug 4820023 on Windows2000, and it soaks up all available RAM and page space, until I get a ‘Your system is running low on virtual memory’ dialog.

Looks like it’s an issue on Win32 as well.

#3

How many buffers are you using? Last time I heard, Java allocates them on page boundaries, so they’ll be allocated in 4KB blocks on Win32. If you’re using lots of small buffers, that overhead can really add up.

Generally buffers should be large, and long lived.

EDIT: Sorry, you know that don’t you? ;D

Yeah, it’s a known problem with buffers - they’re not currently suitable for use in the small.