#1095 Check possible memory leak with unneeded references to closed Editors

[jfirechief]

DO NOT EDIT OR ANSWER THIS ISSUE. SEE THE ORIGINAL ISSUE INSTEAD:
https://www.jfire.org/modules/bugs/view.php?id=1595
ORIGINAL REPORTER: alex

See post https://www.jfire.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=473&forum=10 for details. Basicly it seems that references some Editors don't un-register themselves on close from PartVisibilityTracker and EditLockManager

[jfirechief]

ORIGINAL COMMENT BY marco, VIEW IT HERE:
https://www.jfire.org/modules/bugs/view.php?id=1595

I just took a look at org.nightlabs.jfire.base.ui.editlock.EditLockMan: In the method releaseEditLocks(List<ObjectID> objectIDs, ReleaseReason releaseReason, ProgressMonitor monitor), the EditLockCarrier is removed from the Map objectID2EditLockCarrier, but it seems to not be removed from editLockID2EditLockCarrier anywhere. Probably, the releaseEditLocks method should remove it, too.

I've no time now to test it (thus I don't check-in, yet), but I've already changed the first synchronized block to look like this:

synchronized (editLockCarrierMutex) {
editLockCarrier = objectID2EditLockCarrier.remove(objectID);
if (editLockCarrier != null) {
editLockCarrier.setLastUserActivityDT();
EditLockID editLockID = (EditLockID) JDOHelper.getObjectId(editLockCarrier.getEditLock());
editLockID2EditLockCarrier.remove(editLockID);
}
}

[jfirechief]

ORIGINAL COMMENT BY marco, VIEW IT HERE:
https://www.jfire.org/modules/bugs/view.php?id=1595

In PartVisibilityTracker, I changed the line

private Map<IWorkbenchPart, PartStatus> partStati = new HashMap<IWorkbenchPart, PartStatus>();

to

private Map<IWorkbenchPart, PartStatus> partStati = new WeakHashMap<IWorkbenchPart, PartStatus>();

which should IMHO have no effect onto the application except for correct garbage collection. I did it this way, because it is the easiest way and far less error prone than explicitely unregister all the listeners (in many locations).

Since the IWorkbenchPart instances are held by the Eclipse framework, anyway, they should never be garbage collected before being closed.

Concerning the EditLockCarrier, I'll take a look later, but I can already say, that IMHO these EditLockCarriers should be forgotten after a certain time (they are held by strong references, but there's a timing mechanism for refreshing/cleaning up IIRC).

[jfirechief]

ORIGINAL COMMENT BY marco, VIEW IT HERE:
https://www.jfire.org/modules/bugs/view.php?id=1595

I tested my changes and checked in. It's in the 1.0 branch and in trunk.