Bug 486229 - Memory Leak with org.eclipse.xtext.builder.impl.QueuedBuildData
Summary: Memory Leak with org.eclipse.xtext.builder.impl.QueuedBuildData
Status: NEW
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.4.1   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-21 04:48 EST by Zhang Yaguang CLA
Modified: 2017-06-08 07:48 EDT (History)
3 users (show)

See Also:


Attachments
Mat analysis (48.59 KB, image/png)
2016-01-21 04:48 EST, Zhang Yaguang CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zhang Yaguang CLA 2016-01-21 04:48:32 EST
Created attachment 259294 [details]
Mat analysis

My English is pool,and I will describe the bug as clearly as possible. Thank you first.

During the performance test of our product in IDE,I found the memory increase over 100MB and never recovery after times of FullGC.

Then I dump the Java heap,and found that an instance of org.eclipse.xtext.builder.impl.QueuedBuildData contains 26000 instances of org.eclipse.xtext.resource.impl.ChangedResourceDescriptionDelta ,which retain memory over 90MB.(See the attachment.)

I tried to analyse the problem,fortunately I found when a java file is changed, JavaChangeQueueFiller will add some deltas:

public void elementChanged(ElementChangedEvent event) {
		List<Delta> deltas = deltaConverter.convert(event.getDelta());
		if (deltas != null && !deltas.isEmpty()) {
			queue.queueChanges(deltas);
		}
	}

and the deltas well never be removed unless the project is deleted,which results in the problem.

How can I resolved the problem.Thanks.
Comment 1 Jan Koehnlein CLA 2016-01-21 15:07:46 EST
Hmmm, queued deltas should be removed by the Xtext build (ClusteringBuilderState). Did you turn off "Build automatically"?
Comment 2 Zhang Yaguang CLA 2016-01-22 01:00:51 EST
(In reply to Jan Koehnlein from comment #1)
> Hmmm, queued deltas should be removed by the Xtext build
> (ClusteringBuilderState). Did you turn off "Build automatically"?

If you mean the "Project->Build Automatically" ,no , I keep it selected.

Other world, my projects don't have the nature of XtextNature("org.eclipse.xtext.ui.shared.xtextNature").Will the ClusteringBuilderState work then.Thanks.
Comment 3 Jan Koehnlein CLA 2016-01-22 03:15:28 EST
No, the builder won't run on projects without that nature.

We should analyse whether we fill the queue on projects without that nature or when auto-build is swithed off.
Comment 4 Zhang Yaguang CLA 2016-01-22 03:59:46 EST
(In reply to Jan Koehnlein from comment #3)
> No, the builder won't run on projects without that nature.
> 
> We should analyse whether we fill the queue on projects without that nature
> or when auto-build is swithed off.

In my opinion, JavaChangeQueueFiller should not fill the queue on projects without that nature,so I modify the method elementChanged on my local patch:

public void elementChanged(ElementChangedEvent event) {
		IResourceDelta[] resourceDeltas = event.getDelta().getResourceDeltas();
		if(resourceDeltas != null && resourceDeltas.length > 0){
			IResourceDelta resourceDelta = resourceDeltas[0];
			IResource resource = resourceDelta.getResource();
			if(resource instanceof IProject){
//if the project is invalid,return derectly.				if(!XtextProjectHelper.hasNature((IProject)resource))
					return;
			}
		}
		List<Delta> deltas = deltaConverter.convert(event.getDelta());
		if (deltas != null && !deltas.isEmpty()) {
			queue.queueChanges(deltas);
		}
	}

Then ,the question comes that, will it result in any problem in other situations?

Thanks.
Comment 5 Christian Dietrich CLA 2017-06-08 07:48:40 EDT
see https://github.com/eclipse/xtext-eclipse/issues/70 as well