We investigating using the groovy eclipse plugin in a headless eclipse setup for computing code-completion hints and error messages. To test this, we reloaded a groovy file + requested code completion approximately 1700 times and discovered a memory leak.

The head-dump:

We see that we have in the InstancePreferences object a ListenerList which a size approximately equal to the number of our requests.
There we have NoopCleanUpsAction objects which have an EditorSite attached. We think that this NoopCleanUpsAction objects are created in the GroovyEditor class at line 817-823:

AllCleanUpsAction acua = (AllCleanUpsAction) ReflectionUtils.getPrivateField(GenerateActionGroup.class, "fCleanUp", group);
// GRECLIPSE-966 must dispose action to avoid memory leak
if (acua != null) {
acua.dispose();
ReflectionUtils.setPrivateField(CleanUpAction.class, "fEditor", acua, null);
}
ReflectionUtils.setPrivateField(GenerateActionGroup.class, "fCleanUp", group, new NoopCleanUpsAction(getEditorSite()));

We cannot find GRECLIPSE-966 so we do not understand why line 817-822 is necessary and so we do not know what exactly the need for NoopCleanUpsAction is..., but in line 823 the NoopCleanUpsAction object gets created and we think that this is the origin of the memory leak.

(Our guess is: in NoopCleanUpsAction the dispose function gets overridden without calling super.dispose() ==> this could already be a fix?)