Community
Participate
Working Groups
Here's my scenario: 1) Open a .java file (opens CompilationUnitEditor) 2) Close the editor. 3) observe: there's still an instance of the CompilationUnitEditor hanging around. With a mem profiling tool, I could see that there is a reference chain like this: JavaModelManager->deltaState->deltaProcessors->internalMap->....key->AbstractReconciler$BackgroundThread->JavaReconciler Note that the reconciling thread has been terminated by that time. I'd expect per thread objects to go away when the thread ends (use a weak map, perhaps?)
Good find. 2 issues: - we should convert to ThreadLocal which is tighlty integrated with Thread support and will ensure references are at least disposed when the thread dies. - check whether we are not forgetting to release the offending reference at an earlier stage.
Converted to ThreadLocal. Reconciling path is never clearing the delta processor per thread cache (mistake) since it intends to reuse it across reconciliations. Will rely on thread dying to get rid of cached delta processor. Fixed
Verified under profiler that closing all editors (which had reconciled) leaves no instance of JavaReconciler.
Verified for 3.0M6
