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.

Bug 183832

Summary: Out of memory during idle-time after ~1 hour of work with two very small java projects
Product: ide Reporter: cy6ergn0m <cy6ergn0m>
Component: PerformanceAssignee: Jaroslav Tulach <jtulach>
Status: CLOSED FIXED    
Severity: normal CC: dbalek, dsimonek, jtulach, misterm, sj-nb, thurka, tmysik
Priority: P2    
Version: 3.x   
Hardware: PC   
OS: Linux   
Issue Type: DEFECT Exception Reporter:
Attachments: jvisualvm shows instances of SampleOutputStream.Sample in heap dump

Description cy6ergn0m 2010-04-10 15:28:08 UTC
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
Comment 1 Tomas Hurka 2010-04-12 18:25:58 UTC
There is no problem in profiler. It looks like another manifestation of issue #183201.
Comment 2 cy6ergn0m 2010-04-12 21:23:57 UTC
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
Comment 3 Tomas Pavek 2010-04-13 13:17:00 UTC
*** Bug 183992 has been marked as a duplicate of this bug. ***
Comment 4 Sergey Petrov 2010-04-13 13:24:44 UTC
If it's a real duplicate, then it should be P2 as it cause issue 183992
Comment 5 Jaroslav Tulach 2010-04-13 17:49:23 UTC
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.
Comment 6 Jaroslav Tulach 2010-04-14 07:58:59 UTC
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).
Comment 7 Jaroslav Tulach 2010-04-14 08:08:05 UTC
Tomáši, Dušane, please review my change:
http://hg.netbeans.org/core-main/rev/0b27d337bc62
Comment 8 Jaroslav Tulach 2010-04-14 08:10:17 UTC
It is also possible to turn on detailed logging now:
-J-Dorg.netbeans.modules.editor.completion.CompletionImplProfile.level=ALL
Comment 9 Tomas Pavek 2010-04-14 12:38:35 UTC
*** Bug 184079 has been marked as a duplicate of this bug. ***
Comment 10 Quality Engineering 2010-04-15 05:07:16 UTC
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.
Comment 11 Tomas Pavek 2010-04-27 11:58:49 UTC
*** Bug 185075 has been marked as a duplicate of this bug. ***