Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 183832 - Out of memory during idle-time after ~1 hour of work with two very small java projects
Out of memory during idle-time after ~1 hour of work with two very small java...
Product: ide
Classification: Unclassified
Component: Performance
PC Linux
: P2 (vote)
Assigned To: Jaroslav Tulach
: 184079 185075 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2010-04-10 15:28 UTC by cy6ergn0m
Modified: 2011-05-25 11:40 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT

jvisualvm shows instances of SampleOutputStream.Sample in heap dump (172.19 KB, image/png)
2010-04-10 15:28 UTC, cy6ergn0m

Note You need to log in before you can comment on or make changes to this bug.
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.

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 running on amd64; UTF-8; ru_RU
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:  (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:
Comment 8 Jaroslav Tulach 2010-04-14 08:10:17 UTC
It is also possible to turn on detailed logging now:
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 (upload may still be in progress)
User: Jaroslav Tulach <>
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. ***

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