Community
Participate
Working Groups
Build 20050328 Looking at memory allocation under profiling tool, I got intrigued in seeing 107 live instances of compiler CompilationUnitDeclaration. Checking incoming references, I realized these were kept by DOM AST instances, which in turn were held by 107 open editors. This is a huge waste of space, considering I only have a few active editors. My inclination would be to kill all DOM ASTs as soon as an editor loses focus.
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.
