Memory Leak

OpenGL Development JOGL Development
#1

Hi everyone,
I’d like to ask your advice about something. Is it normal if when I monitor the class instanciated when running a JOGL application, I see the DirectByteBuffer number increasing steadily ?
It happens even with simple demos from jogl-demos, even with a test application that do nothing during the display method of their GLEventListener. For example, I’m currently running the Gears demo, and after 18 minutes, 204 000 DirectByteBuffer instances have been created, for a total size of about 10MB.

Is there a known workAround for this problem ? (JVM, application parameters ?)

Thanks in advance :slight_smile:

#2

Yes, this is normal. JOGL creates some very small direct ByteBuffer instances each frame to refer to C data structures from Java code, but these are very quickly garbage collected. The overall application size does not increase over time.

#3

Um… why not reuse the buffer? you can adjust the ‘base’ field to point to that different (?) C data structure location.

You must be already doing something like that already, as you can’t normally assign a BB to a certain location in memory.

Not that those BB’s are so bad, but when you build an API for high-performance applications, you might want to prevent anything that gets in the way. For example, I only got my renderer really smooth, without any hickups, when I stopped creating any object in the main/render-loops. It’s not always the GC to blame, sometimes the ‘allocator’ seems to ahve some significant delay/overhead (hickups without logs in -verbove:gc)

It wouldn’t be too hard to work around the few new BB’s every frame, would it?

#4

Well, the the overall size of my applications DOES grow. The gears demo is 10Mb larger after 18 minutes than at start up, and every JOGL application I tested grows the same way. I tried it using jogl 1.1.0 final and rc3.

I though DirectByteBuffer were allocated directly (hence their name) in memory, and so could not be collected by the GC.

#5

The native memory is freed when all BB’s that refer to (a portion of) it are GCed.

#6

There is a well-specified way of creating a direct ByteBuffer which points to a given location in memory: the JNI entry point NewDirectByteBuffer(). This is what JOGL (and, more precisely, GlueGen) uses to interact with C structs necessary for the OpenGL and window system operations behind the scenes.

I am very reluctant to change this mechanism to use hacks like mutating a given ByteBuffer. The specification is very clear on what is and is not supported and I want the core JOGL and GlueGen code to be portable to all vendors’ JVMs.

Yeeeeh, what graphics card and OS are you running on? Have you tried running on another machine with a different graphics card? Are you running the latest version of your vendor’s graphics drivers?

It’s possible that the process size isn’t shrinking because some memory is being allocated on the C heap after the transient storage for the direct ByteBuffer is allocated, so even when the direct ByteBuffer’s storage is freed, the C runtime library can’t return the memory to the OS.

If you think there is a memory leak in the core JOGL code then please file a bug with the Issue Tracker on the JOGL home page and I’ll look into it, though this will have to wait until after JavaOne.

#7

I’ll try to run more tests on different machines and os today and see what happens.

Thanks for your time

#8

After more tests… It seems like it was JProfiler that kept references to the memory, because the leak doesn’t occur when you run the applications the normal way. I used JProfiler to keep track of the memory and it was what caused it… :-X

So nevermind, keep up the good work :slight_smile: