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 170625

Summary: Progress UI leaks refresh timers on OSX, leading to high CPU usage
Product: platform Reporter: emi <emi>
Component: ProgressAssignee: t_h <t_h>
Status: RESOLVED FIXED    
Severity: blocker CC: jkovalsky
Priority: P2    
Version: 6.x   
Hardware: Macintosh   
OS: All   
Issue Type: DEFECT Exception Reporter:
Attachments: Progress UI patch to avoid the timer leaks
BTrace script that allows you to see the events being sent and relevant method calls
Huge log file after btrace execution. Notice for example how the org.netbeans.modules.progress.ui.NbProgressBar@2a565e62 instance still gets animated long after discardBar is called on line #1975.
BTrace log file after patch was applied. Note the silence and low number of lines: 1565 compared to over 40000 in the other log.

Description emi 2009-08-19 14:22:09 UTC 
Hy,

I've started investigating this issue when NetBeans (6.5) was taking 14% of my Core2Due 2.4Ghz while being idle.

After profiling, I've notices that of the consumed CPU the spread was:

org.netbeans.core.TimableEventQueue.postEvent (31.3%) + dispatchEvent (5%)
apple.laf.CUIAquaProgressBar$Animator.actionPerformed(25.1%)

So, we were leaking progress bars somewhere.

Armed with a btrace script, I traced the culprit to the NbProgressBar instances that were being leaked in 

progress.ui/src/org/netbeans/modules/progress/ui/ListComponent.java and
progress.ui/src/org/netbeans/modules/progress/ui/StatusLineComponent.java

By leaked I don't mean a normal GC leak but basically the fact that we are not using a workaround to avoid an OSX bug:
each JProgressBar gets a new thread to send repaint events basically in order to achieve that animation effect. The
problem is that the thread is started upon the JProgressBar's creation and stopped only when the bar is taken out from
the container (the problem being that if it was never *added* to a container, we get an ever-lasting thread).

See the attached patch which fixes this issue.

The problem per-se isn't just in Progress UI, it might happen with each (Nb|J)ProgressBar if we just instantiate but
never use it. IDEA had the same problem: http://www.jetbrains.net/jira/browse/IDEADEV-25376

Last time I saw it it was on 

java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)

so not exactly an old JDK.
Comment 1 emi 2009-08-19 14:23:15 UTC 
Created attachment 86457 [details]
Progress UI patch to avoid the timer leaks
Comment 2 emi 2009-08-19 14:29:11 UTC 
Created attachment 86458 [details]
BTrace script that allows you to see the events being sent and relevant method calls
Comment 3 emi 2009-08-19 14:38:46 UTC 
Created attachment 86460 [details]
Huge log file after btrace execution. Notice for example how the org.netbeans.modules.progress.ui.NbProgressBar@2a565e62 instance still gets animated long after discardBar is called on line #1975.
Comment 4 emi 2009-08-19 14:41:05 UTC 
Created attachment 86461 [details]
BTrace log file after patch was applied. Note the silence and low number of lines: 1565 compared to over 40000 in the other log.
Comment 5 Jiri Kovalsky 2009-08-19 14:57:02 UTC 
Tomasi, could you please review Emilian's patch and possibly integrate it if you find no problems? Thanks!
Comment 6 t_h 2009-08-19 15:44:04 UTC 
Good work! Thanks for patch, integrated in core-main #fe8f96e83ea5
Comment 7 Quality Engineering 2009-08-21 06:06:22 UTC 
Integrated into 'main-golden', will be available in build *200908210201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/fe8f96e83ea5
User: Tomas Holy <t_h@netbeans.org>
Log: #170625: Progress UI leaks refresh timers on OSX, leading to high CPU usage