Description Nick Edgar 2005-07-05 16:56:03 EDT

3.1

In bug 84984, Raj Mandayam reports:

Are you sure this patch fixed the problem,
I am involved in developing a product based on Eclipse 3.0.2 that has
a lot of plugins >1000
and my scenario goes like this.

Open our product

1. Open 5 editors for html files,
2. Edit them.
3. Save and then close the editors (I use Ctrl Shift W)
4. I repeat steps 1-3 like 4 or five times
4. I have a sample action that retrieves

	    INavigationLocation[] locations =
TestPlugin.getDefault().getWorkbench().getActiveWorkbenchWindow().getActivePage().getNavigationHistory().getLocations();
	    for (int i = 0; i < locations.length; i++) {
            INavigationLocation location = locations[i];
            if(location != null){
                if(location.getInput() != null)
                System.out.println("location = "+location);
            }
        }


and I noticed there were upto 29 INavigationLocations

that looked like this

 TextSelectionNavigationLocation
      fDocument = <some Document>Document
      fPosition = Position
      fSavedPosition = Position;
      input = FileEditorInput
      page = WorkbenchPage

each of these fDocument's are huge objects
and even if I perform Garbage collect these do not go away

They stay there even after I delete the project, these stay that way

if I make my sample action call INavigationLocation.dispose on each one of them

and then I perform Garbage collect,

I recovered around 130 mb from the heap.


Since I saw this defect and the patch I applied the patch

file NavigationHistory.java to the org.eclipse.ui.workbench (version 3.0.2)

But even after this patch there seems to be no change, the INavigationLocations
retain the fDocument


Is there any other file too for the fix, for example was
TextSelectionNavigationLocation involved in the fix too.

I have a few questions.
1. Is my problem the same as this defect is originally supposed to address
   IF this is a new problem, I hope you can fix it because caching Documents
   which take this much memory does not seem to be a good idea especially 
   in our product which is already big.
2. Is there any other file that was changed for the fix, for example was
TextSelectionNavigationLocation involved in the fix too.
3. I am assuming this fix is not in 3.0.2 but in 3.1RC1 (i verified that)
   

and

I think this has something to do with Multi page editors, and the fact that
their editorPart.getSite().getId() returns "" instead of returning the editor's id

Our scenario

1. We have a editor (a multi page editor) that edits jsp files , i cant be more
specific as this forum is public, i guess,
2. In this scenario we have two files template.jsp and file2.jsp template.jsp
somehow serves as a template for file2.jsp, that is file2.jsp is made up of
template.jsp and its own contents.
3. So whenever both template.jsp is modified, file2.jsp is also modified.
4. In our scenario , both template.jsp and file2.jsp are open in their editors
5. I modify template.jsp and save it, (a navigation entry is added by the editor
for template.jsp, but also a new one is added by the editor for file2.jsp as its
source in the file system is updated)
   normally the id of these editors are com.....HTMLEditor
  and thats what is used as the id when adding such an entry in the
NavigationHistory->NavigationHistoryEditorInfo->editorId

but when the editor for file2.jsp adds the entry in this case (ie when its
source in the file system is replaced) it adds a entry with the editorId = ""
thats because one of the pages of this multi page editor is queried and 
it returns "".

6. After this I hit Ctrl Shift W to close both the editors,
   its noticed that any Navigation entry added by both the editors with their
   editorId is cleaned up, (ie INavigationlocation, FileEditorInput are all
nulled out)
   but this NavigaitionEntry that was added with  the editorId="" still remains 
  in the NavigationHistory's list of histories

and never gets cleaned up.



SINCE this would be hard to reproduce as you do not have our environment, I was
able to come up with a scenario using the base eclipse tools


1. Open Eclipse, import 2 plugins into the Resource perspective, (import with
source)

say the plugins in my case were

org.eclipse.core.boot, let me call it pluginA
and 
org.eclipse.ui.workbench, let me call it pluginB

2. open the pluginxml editor (a multi page editor) for the first plugin
pluginA.xml
   open the pluginxl ediotr for the second plugin
pluginB.xml

3. Now switch to the source view of pluginB.xml and HIGHLIGHT some text
4. Now activate pluginA.xml by clicking on its editor tab.
5. Now go to file system (ie outside Eclipse) and open pluginB.xml in notepad
   and modify it and save it.
6. Now in Eclipse, RIGHT click on pluginB.xml in Navigator view and choose Refresh.

7. Now as before close all editors by hitting Ctrl Shift W
8. Now if you call the sample code like I did to query the document history
  
INavigationLocation[] locations =
TestPlugin.getDefault().getWorkbench().getActiveWorkbenchWindow().getActivePage().getNavigationHistory().getLocations();
	    for (int i = 0; i < locations.length; i++) {
            INavigationLocation location = locations[i];
            if(location != null){
                if(location.getInput() != null)
                System.out.println("location = "+location);
            }
        }

you will see a NavigationHistory holding onto the Document


I think this was because in the code in two place
NavigationHistory.createEntry and in the contstructor for
NavigationHistoryEditorInfo

part.getSite().getId() is called in this case

part= org.eclipse.pde.internal.ui.editor.plugin.ManifestSourcePage  (id=185513500)


which returns "" like the other Multi page of the editor.