Community
Participate
Working Groups
If the plugin is used in anger and the user performs many compiles, a dialog appears reporting that eclipse has run out of memory. I have personally seen it after 30minutes usage (whilst giving a demo!). The underlying problem is perhaps a memory leak in the AspectJ outline view that reflects the crosscutting view for the current file being edited - this view is updated for every compile and may be hanging on to previous versions of its contents.
This may be because getContentOutline (defined in the content outline page class) just asks AJDE for new structure views, it never tells AJDE to discard old views. The structure view manager in AJDE maintains a List of views which is added to each time createViewForSourceFile() is called. The obvious part of the fix is to tell the structure view manager to delete a view just before building another one. However, when this was applied to Adrians codebase, there were problems with the callback onto the outline page not being invoked when the model was updated (e.g. by adding a private field) - this appeared to be because the setRenderer () call made just after calling createViewForSourceFile was not being invoked - the fix here being to remove the condition check that prevents setRenderer being called in some circumstances. However, retrying the first part of the fix today (i.e. just deleting views from the svManager) seems to be sufficient. I wonder if we were guarding the setRenderer calls *because* of the problem of leaving multiple views for the same file registered with the structure view manager. If we did that then the outline page code would potentially be getting multiple calls back from AJDE (one for each view that has been left with the svManager). If we correctly delete views, can we remove the guard ???
The guard can be removde and this problem should now be resolved. Fix is in binary 0.5.2 drop.
