I’m currently running OptimizeIt on my app to track down a memory leak, and notice the following behaviour:
When I open my JGo app (which adds JGoAreas and draws JGoLinks between JGoPorts) and exit, it’s fine.
However, when I open my app and draw a link between 2 JGoPorts and exit, I notice that the MyGoView class (i.e. my extension on JGoView) is not GCed. While checking items that still reference this JGoView, it looks like the culprit is JGoSelection. I’ve tried ensuring that nothing is selected before I exit, but it hasn’t helped.
I realise it’s difficult to offer a perspective on this without being close to the problem, but any help would be appreciated. I’m using JGo1.5, JDK1.4.2.
I assume you are using JGo 5.1, not 1.5, which never existed.
JGoSelection should always have a backpointer to its JGoView. Furthermore there’s always a JComponent reference held statically by JGoGlobal.getComponent(), which is used in a few circumstances.
Could I ask what the problem really is? Having some JComponents around when it exits shouldn’t be a problem, since the operating system resources will be recovered. Are you having some sort of memory leak problem while your application is running, and you happened to notice this behavior on exit, but the real problem is elsewhere?
Perhaps the memory usage is coming from the UndoManager. You might want to limit it by calling UndoManager.setLimit.
Also I didn’t think that a GC is normally done upon an exit. Perhaps running OptimizeIt forces a GC to improve its statistics.
Sorry Walter;
- I’m numerically dyslexic when it comes to releases, so it is indeed 5.1
- When I say “exit”, I actually mean that the JVM is still active - I’m just exiting from a sub-app which uses this JGoView extension (MyGoView) back to the main part of the app.
I’ve actually narrowed it down to drag’n’drop. If I create a link or just drag one of my JGoAreas to another location on the view, the view isn’t GCed.
I’ll keep digging and appreciate the reply.