Summary: | [performance] Editors keeping huge amount of resolved DOM ASTs | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Philipe Mulet <philippe_mulet> | ||||
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||
Status: | RESOLVED WONTFIX | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P2 | CC: | daniel_megert, dirk_baeumer, panagiotis.korros | ||||
Version: | 3.1 | Keywords: | performance | ||||
Target Milestone: | 3.1 M7 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Philipe Mulet
2005-03-28 15:48:48 EST
Can you provide the profiler output which shows who holds the references? We only cache one AST over all windows. It would be interesting to see who holds on to them. Reassigning. After investigation, it seems the leak occurs DOM AST conversion mechanism. Investigating a fix. Basically, the conversion process keeps in cache all alternate compiler AST&bindings requested during converted units. Addressing this should avoid the leak in single DOM unit creation, and avoid resolving alternate units in batch DOM unit creation case. Released support for the pipeline scenario in M6. Left untouched the scenario for single unit resolution (used during reconciliation) since forcing faulting the types in for all requested units (so can cleanup afterwards) is inducing perf slow down. Also, there are still references to cleaned units through the scope map of the resolver. The only way to get rid of all scopes after the conversion is to resolve all qualified type reference, qualified name reference and import references immediately. Right now some binding resolution is done lazily, but this requires the scopes to be available. For the reconciler, the cleanup needs to be done for the compilation unit problem finder. The requested cus are not stored right now and this makes it impossible to clean them up. I suggest to store them and to iterate the collection at the end of the process to resolve all bindings with failInTypes() and then clean them up. Created attachment 19646 [details]
Apply on HEAD
Using this patch, I can clean up requested units. I had to change the
registration of the units, because it is possible to find a path where the
collection was null.
Philippe, could you please have a look at the patch?
Daniel, can the visitor used on the reconcile dom tree not visit each name? Resolving each name is expensive and I don't believe this is useful for all names. For example, if you have something like this: import org.eclipse.swt.graphics.Point; import org.eclipse.swt.graphics.Rectangle; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Control; import org.eclipse.swt.widgets.Shell; import org.eclipse.jface.dialogs.IDialogConstants; import org.eclipse.jface.dialogs.IDialogSettings; import org.eclipse.jface.operation.IRunnableContext; import org.eclipse.ui.PlatformUI; import org.eclipse.jdt.core.search.IJavaSearchScope; import org.eclipse.jdt.internal.ui.IJavaHelpContextIds; import org.eclipse.jdt.internal.ui.JavaPlugin; ... Each subpart of each import reference ends up being resolved. I don't think that this is useful. This might require its own PR. Olivier, I do not understand your question. There are many clients of this shared AST. Many different visitors are used to traverse it, there's not a single "reconcile" AST visitor. Then I don't plan to change anything for the reconciling case. Philippe, ok to close as WONTFIX? +1 Close as WONTFIX. There is no optimization that can be done in the reconcile case. The usage of this DOM tree is dependant of the user's settings. Therefore we cannot force the resolution of requested units in all cases. |