Well, with a little patience I could see data coming in. Pretty soon I noticed at the top of the list two classes that shouldn't have been there:
org.netbeans.core.TimableEventQueue.postEvent with 31.3%
apple.laf.CUIAquaProgressBar$Animator.actionPerformed with 25.1%
org.netbeans.core.TimableEventQueue.dispatchEvent with 5%
So, it looked like the EventQueue (well, the one used by NetBeans IDE anyhow) was being really busy this whole time calling an OSX-specific ProgressBar animator class. The only thing was -- there was no progress bar on the screen! Actually, the whole NetBeans IDE was hidden away... so Swing should have been really quiet.
Well, it started looking as if we had some sort of "leak" here, i.e., some object that clearly isn't being disposed properly. I instantly thought that the culprit might be some class inside the NetBeans Progress API/UI, since this is the module that shows that little progress component in the lower-right corner of the main window. This was just a hunch, though, since I know a bit about the internals of NetBeans IDE, but I had no way to prove it yet or, more importantly, to fix it.
I returned to VisualVM knowing what classes to look for and I requested a heap dump. This is a snapshot of the applications' memory at that point. I went into the Classes tab and I searched for our CUIAquaProgressBar$Animator class:
Now my reasoning was to find some JProgressBar reference and, sure enough, using the Fields area in the Instances tab I found a link to the progress bar:
OK, so indeed we have some wild JProgressBars being called, more to the point NbProgressBars. We are actually getting somewhere now!