GLDrawableHelper hanging on to references?

JOGL 2.1.5

We have an application that allows users to open and close multiple windows, each with its own GLCanvas. A shared drawable is used to share textures.

We've noticed that when windows are closed, memory usage doesn't go down as much as we expect. Profiling shows that GLCanvas objects are hanging around. Some investigation shows that GLDrawableHelper has a ThreadLocal<Runnable> perThreadInitAction that has Runnables added to it, but seemingly never removed. Since these are GLCanvas init actions, GLCanvas instances are being indirectly referenced from perThreadInitAction, so the GLCanvas instances can't be garbage collected.

Also, GLContextShareSet.registerSharing() adds references between contexts, but again seemingly the references aren't removed when a context is disposed.

As far as we can tell, we're calling dispose() in the right places, but of course we might be missing some. Our application is fairly large, so a reproducer could be time consuming. Before we start, does anyone have any ideas about where we might look?

Thanks.

PJDM

Hi

If you're right, it should be reproducible even with the most simple existing examples, shouldn't it?

On 06/23/2014 02:04 PM, PJDM [via jogamp] wrote:
> JOGL 2.1.5
>
> We have an application that allows users to open and close multiple windows,
> each with its own GLCanvas. A shared drawable is used to share textures.

We have [at least] three unit tests to test this scenario, e.g:
  src/test/com/jogamp/opengl/test/junit/jogl/acore/TestAddRemove03GLWindowNEWT.java
  src/test/com/jogamp/opengl/test/junit/jogl/acore/TestAddRemove01GLCanvasSwingAWT.java
  src/test/com/jogamp/opengl/test/junit/jogl/acore/TestAddRemove02GLWindowNewtCanvasAWT.java

yes, they make most sense w/ a running profiler .. etc.

>
> We've noticed that when windows are closed, memory usage doesn't go down as
> much as we expect. Profiling shows that GLCanvas objects are hanging around.
> Some investigation shows that GLDrawableHelper has a
> ThreadLocal<Runnable> perThreadInitAction that has Runnables added to it, but
> seemingly never removed. Since these are GLCanvas init actions, GLCanvas
> instances are being indirectly referenced from perThreadInitAction, so the
> GLCanvas instances can't be garbage collected.

Thank you, looks like you are correct and we need to use a WeakReference!
Excellent finding.

Indeed, our unit tests only utilize simple GLEventListener
or even reuse the same and hence the growing GC will not be visible [that much].

Please create a bug report, maybe even a fix ?
(Will do both later .. if nobody does)

>
> Also, GLContextShareSet.registerSharing() adds references between contexts,
> but again seemingly the references aren't removed when a context is disposed.
>
GLContextShareSet.unregisterSharing() is called via GLContextImpl.destroy()
for the last (or only) shared context.
It shall remove all artifacts.

This was fixed in commit 5d33b0a3ef993ff2d257c90abc3d84bc93269cd0.

Maybe we have to double check whether there is still an issue with this code.

> As far as we can tell, we're calling dispose() in the right places, but of
> course we might be missing some. Our application is fairly large, so a
> reproducer could be time consuming. Before we start, does anyone have any
> ideas about where we might look?

Maybe it's a side-effect of above issue ..
>
> Thanks.
>
> PJDM
>

~Sven

Did a bug get filed for this? I can't find one, but that could be my searching skill. I'm happy to copy/paste the text if not.

Thanks.

PJDM

Sven fixed this bug, he used some weak references, it should be ok now. Please use the very latest build (currently 2.2.0 RC 20140731).

On 08/04/2014 03:25 PM, gouessej [via jogamp] wrote:
> Sven fixed this bug, he used some weak references, it should be ok now. Please
> use the very latest build (currently 2.2.0 RC 20140731).

Yup.

Pls see Bug 1029 <https://jogamp.org/bugzilla/show_bug.cgi?id=1029>

~Sven

Brilliant, thanks.

PJDM