Native buffer problem - out of memory error

[curmoISU]

I'm having quite a problem..  The JVM doesn't seem to be garbage collecting my native buffers..  So, the memory goes crazy when I'm rendering until the point an outofmemory error occurs when trying to allocate another FloatBuffer.

The way my render works is in the render method I say "render this list of similar triangles" where similar means triangles with teh same texture so they can all be rendered in one group using a vertex array..  So, I allocate a FloatBuffer for the vertices, etc. using BufferUtils.createFloatBuffer  , render the vertexarray, and then I'm done with it..   Of course, this can happen many many times when particle systems, actors, world geometry, etc. is factored in.  When all of that is combiined they just don't seem to get freed fast enough and the JVM blows up..

So, some suggestions might be to create one big buffer and reuse it, but, the question is, how can I do that effectively in a large, complex scene?  The # of triangles in the scene is constantly changing/growing/shrinking (with particles, actors being added/removed/etc)....  So I just don't know what to do.  Any help would be -greatly- appreciated!!  This is completely crippling my work.

[tomb]

Running out of memory because it is not gcing is a know problem with buffers. But you never wan't to create a new buffer every frame anyway. Not only will you run out of memory, it's also incredibly slow.

You have to reuse the buffers. You don't have to use the whole buffer. Use position() and limit() to mark the region that you are using. Depending on how you do your rendering, you can use one big buffer, or one buffer for each possible state. A buffer don't have to fit all triangles at once. Check if it is full, and flush it if it is. Then reset the buffer.

[atze]

just ported my app from jogl to lwjgl. was almost easy.
now i get this thingy:

Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory
	at java.nio.Bits.reserveMemory(Bits.java:625)
	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:95)
	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:285)
... more stack for creating textures ...

i used int[] and byte[] in jogl. lwjgl forced me to use IntBuffer and ByteBuffer instead. that might be faster but it kills my app totaly. i have to create new textures all along (rendering nice looking text). i can not reuse the buffers, i just have to much different textures.

how do i solve that problem? it worked with jogl and arrays (uh, yes i have a reason for porting to lwjgl now and abandoning jogl).
any good idea is welcome!

[Orangy Tang]

i have to create new textures all along (rendering nice looking text). i can not reuse the buffers, i just have to much different textures.

Once your texture data has been uploaded to GL (via glTexImage2D or similar) then you can discard (or reuse) the buffer as GL will copy it and manage it itself (until you call glDeleteTextures that is).

[atze]

discarding the buffers (buffer = null) did help.

is there any way to enlargen the buffer space?
-Xmx768m instead of -Xmx512m did not change a thing for the buffers.

[princec]

Yes. There is system property you can set - direct buffers are independent of the Java heap and therefore the -Xmx setting has no effect on them. The property is -XX:MaxDirectMemorySize=256M (for example)

Cas

[Fool Running]

Yes. There is system property you can set - direct buffers are independent of the Java heap and therefore the -Xmx setting has no effect on them. The property is -XX:MaxDirectMemorySize=256M (for example)

I did not know that   . That's very usefull (not that I need that yet)  :lol: