Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 143593 - Leak of project via JavaSource
Leak of project via JavaSource
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Source
6.x
All All
: P3 (vote)
: 6.x
Assigned To: Jan Lahoda
issues@java
perfleak
: PERFORMANCE, TEST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-12 10:57 UTC by Jaroslav Tulach
Modified: 2009-09-04 03:51 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Patch that eliminates the leak in parsing API. Hanzi, please evaluate (11.49 KB, patch)
2009-08-31 16:24 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-08-12 10:57:43 UTC
While working on issue 143590 (and after applying its patch 
http://www.netbeans.org/nonav/issues/showattachment.cgi/67131/X.diff) I get following memory leak:


private static final java.util.Map org.netbeans.api.java.source.JavaSource.finishedRequests->
java.util.WeakHashMap@12d0266-table->
[Ljava.util.WeakHashMap$Entry;@5b5669-[6]->
java.util.WeakHashMap$Entry@f54356-value->
java.util.LinkedList@f1ba4b-header->
java.util.LinkedList$Entry@b93dfa-next->
java.util.LinkedList$Entry@1a58b49-element->
org.netbeans.api.java.source.JavaSource$Request@f213e4-javaSource->
org.netbeans.api.java.source.JavaSource@7feca0-classpathInfo->
org.netbeans.api.java.source.ClasspathInfo@af516d-srcClassPath->
org.netbeans.api.java.classpath.ClassPath@745d25-impl->
org.netbeans.spi.java.project.support.ClassPathProviderMerger$ProxyClassPathImplementation@fdd079-mainProvider->
org.netbeans.modules.java.j2seproject.classpath.ClassPathProviderImpl@4dab8c-sourceRoots->
org.netbeans.modules.java.api.common.SourceRoots@163b86f-helper->
org.netbeans.modules.java.api.common.ant.UpdateHelper@d070e9-updateProject->
org.netbeans.modules.java.j2seproject.UpdateProjectImpl@1405b99-project->
org.netbeans.modules.java.j2seproject.J2SEProject@1506a1e

What makes me wonder is why "finishedRequests" is a weakhashmap, when its value JavaSource$Request@f213e4 seems to 
have strong reference back to its key "javaSource"? Shall not the finishedRequest list be made an instance variable of 
JavaSource, anyway?
Comment 1 Jan Lahoda 2008-08-12 12:11:54 UTC
Actually related to what we discussed - if the events won't reach the factories correctly, the factories will not fire
correctly their events, and so the tasks will never be unregistered. Given that the tasks are the only thing that keeps
the JavaSource in memory (to my knowledge), and that the only thing that keeps the tasks in memory is (or should be
unless we want to leak *a lot*) the JavaSource, simply making it "all weak" is very likely to completely break Java support.

BTW: this seems like a "last one" problem - wouldn't it make sense to make the test immune to the "last one" problem
(opening a .txt file in the editor should be enough), and concentrate our efforts on hunting cumulative leaks?
Comment 2 Jaroslav Tulach 2008-08-12 14:26:36 UTC
Re. events - if you know what is wrong, please assign to person that generates the events incorrectly. I do not know 
anything about that.

Re. "last" - I am quite fine with fixing this problem by changing the test to do some additional actions. Again, feel 
free to modify it to open some new java file, parse it, etc. Tricks are allowed to satisfy our main goal: be able to 
successfully call assertProjects() after some set of UI operations.
Comment 3 Jan Becicka 2008-08-14 10:08:00 UTC
> Re. events - if you know what is wrong, please assign to person that generates the events incorrectly. I do not know 
> anything about that.

Sounds reasonable. Honzo, Who does not fire events correctly?

> Re. "last" - I am quite fine with fixing this problem by changing the test to do some additional actions. Again, feel 
> free to modify it to open some new java file, parse it, etc. Tricks are allowed to satisfy our main goal: be able to 
> successfully call assertProjects() after some set of UI operations.

If the fix of this small memory leak is risky, this bug is wantfix. Anyway we can help you with some workarounds in
tests. Come and ask Honza how to do it yourself ;)
Comment 4 Jaroslav Tulach 2008-08-15 09:20:16 UTC
Do you have some data to justify your attempt to call this "small memory leak"? Unless you provide them, let's treat 
this report as regular memory leak, please.
Comment 5 Jan Becicka 2008-08-15 09:54:43 UTC
I take "small" back.

Data on justification of impact and how big is this memory leak is up to you, Jardo ;)

i just wanted to say, that fixing of memory leak which is not big (and I bet, that this issue will be p2 if the memory
leak is big) and not cumulative with possible negative impact on quality is something which we don't want to do.
Comment 6 Jaroslav Tulach 2008-08-15 16:42:32 UTC
My trouble is that without this issue being fixed, I am not able to eternally confirm that the leak is not cumulative. 
I need to fix all leaks regardless of their size before I can write test and make it part of commit validation. In 
this sense the leak "blocks developer progress", but I do not want to make it P2 now, as the goal of preventing leaks 
of projects is just P3 for us in 6.5 release.
Comment 7 Rastislav Komara 2009-02-03 10:56:49 UTC
Overtake.
Comment 8 Rastislav Komara 2009-05-06 15:32:46 UTC
@jtulach: Is this issue still valid? jlahoda in our discussion said it should be invalid yet. Please, can you verify
this issue again?
Comment 9 Jaroslav Tulach 2009-05-12 08:25:51 UTC
Should you have run the test yourself instead of playing with INCOMPLETE keyword, you would find out that leak 
through "java source" still exists:

private static java.util.Collection org.netbeans.modules.parsing.impl.Schedulers.taskSchedulers->
java.util.Collections$UnmodifiableRandomAccessList@8b2aba-list->
java.util.ArrayList@1391fc2-elementData->
[Ljava.lang.Object;@1768386-[0]->
org.netbeans.modules.parsing.impl.CurrentDocumentScheduler@18906e4-source->
org.netbeans.modules.parsing.api.Source@95d96-cache->
org.netbeans.modules.parsing.impl.SourceCache@1f65cee-parser->
org.netbeans.modules.java.source.parsing.JavacParser@4babb8-cpInfo->
org.netbeans.api.java.source.ClasspathInfo@e2bc6e-srcClassPath->
org.netbeans.api.java.classpath.ClassPath@1bfe8c0-impl->
org.netbeans.spi.java.project.support.ClassPathProviderMerger$ProxyClassPathImplementation@13d8c61-mainProvider->
org.netbeans.modules.java.api.common.classpath.ClassPathProviderImpl@18ccc5e-helper->
org.netbeans.spi.project.support.ant.AntProjectHelper@1931e4-state->
org.netbeans.api.project.ProjectManager$ProjectStateImpl@3c304a-p->
org.netbeans.modules.java.j2seproject.J2SEProject@1fc0932
Comment 10 Jaroslav Tulach 2009-05-12 09:16:19 UTC
After my changeset http://hg.netbeans.org/ergonomics/rev/22bd852800e3 there seems to be only one last leak (again 
through "java source"):

static final org.openide.util.Lookup 
org.netbeans.modules.project.ui.actions.LookupSensitiveAction$LastActivatedWindowLookup.INSTANCE->
org.netbeans.modules.project.ui.actions.LookupSensitiveAction$LastActivatedWindowLookup@1ff7a62-reg->
org.netbeans.core.windows.RegistryImpl@faff12-support->
java.beans.PropertyChangeSupport@102aae6-listeners->
sun.awt.EventListenerAggregate@6edbc7-listenerList->
[Ljava.beans.PropertyChangeListener;@398a1e-[3]->
org.netbeans.modules.parsing.impl.SelectedNodesScheduler$AListener@149293d-this$0->
org.netbeans.modules.parsing.impl.SelectedNodesScheduler@1c10172-source->
org.netbeans.modules.parsing.api.Source@15f0bad-cache->
org.netbeans.modules.parsing.impl.SourceCache@494403-parser->
org.netbeans.modules.java.source.parsing.JavacParser@10f4211-cpInfo->
org.netbeans.api.java.source.ClasspathInfo@a1d3e9-srcClassPath->
org.netbeans.api.java.classpath.ClassPath@4a0c21-impl->
org.netbeans.spi.java.project.support.ClassPathProviderMerger$ProxyClassPathImplementation@c76b3c-classPaths->
[Lorg.netbeans.spi.java.classpath.PathResourceImplementation;@18f5229-[0]->
org.netbeans.spi.java.project.support.ClassPathProviderMerger$ProxyFilteringCPI@ce5cf-classpath->
org.netbeans.api.java.classpath.ClassPath@1842212-impl->
org.netbeans.modules.java.api.common.classpath.SourcePathImplementation@1811196-sourceRoots->
org.netbeans.modules.java.api.common.SourceRoots@699803-helper->
org.netbeans.modules.java.api.common.ant.UpdateHelper@e805a7-updateProject->
org.netbeans.modules.java.j2seproject.UpdateProjectImpl@37d8fa-project->
org.netbeans.modules.java.j2seproject.J2SEProject@858c07
Comment 11 Jaroslav Tulach 2009-08-13 17:35:22 UTC
Jan, as negotiated by Víťa and Moonko, I will now be helping you to fix this issue.
Comment 12 Jan Lahoda 2009-08-21 12:32:11 UTC
I have identified several places in the jet area that were holding the last project:
-cache in CodeStylePreferences: the cache uses WeakHashMap, but after the project is closed, no-one touched the cache
(understandably), and so some values in the cache have survived.
-BeansPanel in beans module held itself statically
-Schedulers do not support "unscheduling" (the last scheduled source is held forever)

I have fixed the first two problems:
jet-main b4b625ba8e7c

I have contacted Hanz with a possible fix to the third problem.

Anyway, after fixing these problems, the test sometimes passes, sometimes not. Below, I will list the dumps that I have
seen. Once, I have even seen that insane was not able to find who is holding the reference. Before enabling the test,
please make sure it is very stable - parallel integration does not work well with unstable tests.

private static org.netbeans.core.ide.ServicesTab org.netbeans.core.ide.ServicesTab.DEFAULT->
org.netbeans.core.ide.ServicesTab@1ef1245-parent->
javax.swing.JPanel@d94cd8-component->
[Ljava.awt.Component;@18e9635-[0]->
org.netbeans.modules.project.ui.ProjectTab@1b29b56-btv->
org.netbeans.modules.project.ui.ProjectTab$ProjectTreeView@a8253a-searchTextField->
org.openide.explorer.view.TreeView$8@ae1008-keyListener->
org.openide.explorer.view.TreeView$ExplorerTree$SearchFieldListener@3231ed-results->
java.util.ArrayList@d42c65-elementData->
[Ljava.lang.Object;@eb3254-[1]->
javax.swing.tree.TreePath@d12eb4-lastPathComponent->
org.openide.explorer.view.VisualizerNode@da853b-node->
org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode@1b34c53-pair->
org.netbeans.modules.project.ui.ProjectsRootNode$ProjectChildren$Pair@d3a7bd-project->
org.netbeans.modules.java.j2seproject.J2SEProject@14d160c

private static sun.awt.im.InputContext sun.awt.im.InputContext.inputMethodWindowContext->
sun.awt.im.InputMethodContext@1dc21e5-compositionAreaHandler->
sun.awt.im.CompositionAreaHandler@1e439f-clientComponent->
org.openide.explorer.view.TreeView$ExplorerTree@1d65df9-this$0->
org.netbeans.modules.project.ui.ProjectTab$ProjectTreeView@236c8b-searchTextField->
org.openide.explorer.view.TreeView$8@11aeef1-keyListener->
org.openide.explorer.view.TreeView$ExplorerTree$SearchFieldListener@1488dd9-results->
java.util.ArrayList@122ea66-elementData->
[Ljava.lang.Object;@1a8e1e2-[1]->
javax.swing.tree.TreePath@195ae70-lastPathComponent->
org.openide.explorer.view.VisualizerNode@1350500-node->
org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode@117e412-pair->
org.netbeans.modules.project.ui.ProjectsRootNode$ProjectChildren$Pair@1fa26c5-project->
org.netbeans.modules.java.j2seproject.J2SEProject@14c4f70

private static java.util.Map org.netbeans.modules.project.ui.ProjectTab.tabs->
java.util.HashMap@17dbcb6-table->
[Ljava.util.HashMap$Entry;@4835ee-[10]->
java.util.HashMap$Entry@31fd76-value->
org.netbeans.modules.project.ui.ProjectTab@a68033-btv->
org.netbeans.modules.project.ui.ProjectTab$ProjectTreeView@1585cf8-visHolder->
org.openide.explorer.view.TreeView$VisualizerHolder@30aac8-map->
java.util.HashMap@9ac4f2-table->
[Ljava.util.HashMap$Entry;@18b21e5-[13]->
java.util.HashMap$Entry@82f48-key->
org.openide.explorer.view.VisualizerChildren@1f0c908-snapshot->
org.openide.nodes.EntrySupport$Default$DefaultSnapshot@1c24d52-holder->
org.openide.nodes.ChildrenArray@17aad28-map->
java.util.WeakHashMap@57a75a-table->
[Ljava.util.WeakHashMap$Entry;@b8efe9-[0]->
java.util.WeakHashMap$Entry@3f668d-value->
java.util.LinkedList@fe34e6-header->
java.util.LinkedList$Entry@10db748-next->
java.util.LinkedList$Entry@130acca-element->
org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode@1523ef9-pair->
org.netbeans.modules.project.ui.ProjectsRootNode$ProjectChildren$Pair@12d651-project->
org.netbeans.modules.java.j2seproject.J2SEProject@14c4f70
Comment 13 Jaroslav Tulach 2009-08-21 13:39:40 UTC
Thanks for fixing the issues in editor. The three remaining problems seem to be in explorer. So as soon as the one 
remaining Hanz's problem is fixed, we can reassign to Tomáš Holý, I guess. Tomáši, can you think of fixing 
SearchFieldListener to clean paths that are no longer present in the tree? Do you want to solve it as part of this bug 
or do you want me to report some new one?
Comment 14 t_h 2009-08-24 15:15:37 UTC
SearchFieldListener fixed in core-main #c5a62846be23
Comment 15 Quality Engineering 2009-08-25 02:44:05 UTC
Integrated into 'main-golden', will be available in build *200908242212* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/c5a62846be23
User: Tomas Holy <t_h@netbeans.org>
Log: #143593: clear search results on search field close
Comment 16 Jaroslav Tulach 2009-08-31 16:24:28 UTC
Created attachment 86868 [details]
Patch that eliminates the leak in parsing API. Hanzi, please evaluate
Comment 17 Jan Lahoda 2009-08-31 16:36:34 UTC
I have already pushed a change (to jet-main) that should eliminate the Scheduler's references - however, the parallel
integration builders where not able to build a daily build with this change since Friday.
Comment 18 Quality Engineering 2009-09-03 08:44:14 UTC
Integrated into 'main-golden', will be available in build *200909021401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/c789a7a8ea30
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #143593: making sure the standard schedulers clear there internal structures when the last document is closed.
Comment 19 Jaroslav Tulach 2009-09-03 09:31:08 UTC
Jan's changes are in, so I am enabling the test: core-main#52f3cfe42459

If you see the testGCProjects fail on your builders, please report a bug for me and feel free to temporarily backout 
52f3cfe42459 so your integrations are not prevented.

Comment 20 Quality Engineering 2009-09-04 03:51:48 UTC
Integrated into 'main-golden', will be available in build *200909032054* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/52f3cfe42459
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: The bug #143593 is fixed, the testGCProjects seems to pass for me and Tom�? Hol�, so let's enable the test and see if it passes for everyone.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo