Posted by Sven Gothel on Jun 23, 2014; 2:20pm
URL: https://forum.jogamp.org/GLDrawableHelper-hanging-on-to-references-tp4032475p4032478.html

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