Memory leak

I am using V1.1.1a with an application that displays 3D diagrams.

The memory usage cycles up and down, mainly caused by java.nio.DirectDoubleBuffer. That is probably just normal garbage collection.

However I also use GLPbuffer for creating static images of the 3D graphics. After doing that, I find that the range of fluctuation due to DirectDoubleBuffer is quite a lot larger. It is as if static image code is still grabbing buffers even though it has, AFAIK, been released. Each time I create an image, the total amount of memory taken before GC increases by 20MB or so.

This isn't technically a memory leak, because the buffers are always freed eventually. But I fear that if someone created a number of images the allocations might use up all memory before the GC kicked in.

Anyone have any pointers as to what I might be missing?

On 10/21/2011 06:51 PM, Tomd [via jogamp] wrote:
> This isn't technically a memory leak, because the buffers are always
> freed eventually. But I fear that if someone created a number of
> images the allocations might use up all memory before the GC kicked in.
  you don't have to fear this scenario since the GC *will* kick in as
soon the heap is full. All throughput collectors are very lazy in
cleaning up. Why should they release resources if they don't have to?
(possible GC triggers for the old generation are: heap fragmentation,
concurrent cleanup thresholds or out of memory)

so actually to find out the actual mem consumption of your application
you can check out the used heap value right after a full GC (you can
trigger this with visualvm or other tools).

large objects like large byte arrays are often allocated directly in the
old generation of the heap, thats why they survive longer as the small
ones. Direct NIO buffers get special treatment (this is about to change
in future JVM updates) and are allocated in a even more lazy area (next
to stuff like the class files). So consider using direct nio buffers as
static allocated memory instead of allocating them in inner loops.

regards,
michael

Thanks.

I should probably have been more clear, I am not doing anything special or clever with the buffers, I am doing everything with the JOGL API. I just see from the memory profiler that it is these objects which are responsible for the continuous rise and fall of heap usage. Presumably JOGL is creating these internally.

Maybe it is just an oddity of the GC. I will try stress testing it later.

Hi

At first, as it is not a memory leak, why is your topic entitled "memory leak"? It is just excessive and you're using an obsolete version of JOGL, please switch to JOGL 2.0 and write a bug report if necessary.

It isn't technically a memory leak. It is unexpected behaviour which might cause the program to fail by running out of memory. Memory leak seems close enough to use as a summary.

There is no suggestion here that the memory leak is in JOGL, I just thought I might be doing something wrong, failing to dispose or close something, and somebody who knows how the buffers are used might recognise the problem.

There don't seem to be a lot of examples of GLPbuffer, but I can't see any other way of creating large images. Is there a better way with JOGL 2?