This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 97011 [details] jvisualvm shows instances of SampleOutputStream.Sample in heap dump After ~1 hour of work with two very small java projects i ran away and netbeans still running. After a while I found that netbeans crashed with OutOfMemoryError. I looked into heap dump (~450M) and I saw that most of objects (42% by size) are arrays of ojects. Two largest Object[] are arrays into ArrayList<SampleOutputStream.Sample> thats are fields of SampleOutputStream.samples. These SampleOutputStream used from SelfSampleAction.Controller class at field samplesStream. This action used from TimerTask. Also I found very much of little ArrayList<SampleOutputStream.Sample> In addition these "samples" holds many many instances of java.lang.Long thats are ~30% of all instances in heap (by quantity). Largest list holds ~400.000 of SampleOutputStream.Sample instances. View of visual vm for one of these instances are in attachment. Environment: Product Version: NetBeans IDE Dev (Build 100409-7960d58c7f86) Java: 1.6.0_16; Java HotSpot(TM) 64-Bit Server VM 14.2-b01 System: Linux version 2.6.31.12-desktop-3mnb running on amd64; UTF-8; ru_RU (nb) Userdir: /home/cy6ergn0m/.netbeans/dev
There is no problem in profiler. It looks like another manifestation of issue #183201.
I have heap dump yet... if you are insterested in you may download it here: http://files.fealot.ru/heapdump-netbeans.hprof.bz2 (56M) md5: 21d2745c7bdcba055ef9e03f8fbabc7b
*** Bug 183992 has been marked as a duplicate of this bug. ***
If it's a real duplicate, then it should be P2 as it cause issue 183992
I have the snapshot. With help of Dušan Bálek we managed to find few problems in the CC slowness sampling code. I am adding more logging, and improving the code. The patch will be ready tomorrow.
The snapshot really helped. It shows two self-profiling threads running without anyone having a pointer to them (e.g. no way to stop them). I will make the code more bullet proof and make sure the previous self-profiling in code completion is always stopped. Also I am adding yet another stopProfiling() call when the editor component is switched (which has been identified by Dušan as one additional place the code completion can be hidden).
Tomáši, Dušane, please review my change: http://hg.netbeans.org/core-main/rev/0b27d337bc62
It is also possible to turn on detailed logging now: -J-Dorg.netbeans.modules.editor.completion.CompletionImplProfile.level=ALL
*** Bug 184079 has been marked as a duplicate of this bug. ***
Integrated into 'main-golden', will be available in build *201004150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/0b27d337bc62 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #183832 and #183201: Splitting out the CompletionImplProfile into own top level class. Deducing the 'since' time from current time, as the task can be executed repeatedly. stopProfiling whenever pleaseWaitTimer.stop() is called. Don't profile if assertions are off. stopProfiling before allocating new CompletionImplProfile. stopProfiling when setEditorComponent is called. Make the profiler field final, so its reference cannot be 'lost'. Make sure the stop() method either gets the snapshot or calls cancel.
*** Bug 185075 has been marked as a duplicate of this bug. ***