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.
I just started using NB 6.5.1 at work for real and am working with a 6000 file local mercurial repository containing the SunStudio dbxgui module (plus others) Occasionally Mercurial->status will just go on and on and on and on ... It's happened twice now ... and NB becomes unusable. I hesitate to kill NB because it's likely updating persistent data structures. I've waited for one hour and then decided to file this bug. It seems to be a CPU dominating activity which swamps out the eventQ so the NB UI doesn't get refreshed. truss'ing the Java running NB shows very few system calls ... just the occasional open() of stuff in userdir/caches/mercurial. A typical thread dump follows.
Created attachment 84277 [details] thread dump while mercurial->status is very busy
Looking in the log file shows me a bunch of OOM's. log file attached. I suppose the OOM's mess up the state and send DiskMapTurboProvider into unknown territory?
Decided the OOm's are irrelevant. I started a fresh NB and did another Mercurial->Status from the favorites view and it's already busy busy busy but no OOM's yet in the log. Instead attaching a thread dump from the early part of the busyness
Created attachment 84278 [details] another thread dump
1) All thread dumps look alike? It always hangs in the DiskMapTurboProvider? 2) Could you please pack and send me the mercurial cache folder? - ~/.netbeans/6.5/var/cache/mercurialcache. Mercurial has sometimes problems with a huge cache and it's access on the disk takes a long time (some people use to have .hg in their home folder which results in it's complete scan). 3) The second dump shows DiskMapTurboProvider.getAllModifiedValues operating in the AWT, which has been recently eliminated. Could you please try the latest dev build? - http://bits.netbeans.org/download/trunk/nightly/latest/ 4) 6.7 (or dev builds) has also a nice tool, which could help us a lot in analyzing the problem. Could you check it and attach a profiler snapshot? http://wiki.netbeans.org/FaqProfileMeNow
I'll send 4 snapshots and the cache in a separate email. I took a few more snapshots and this is what I observed. It is the "Mercurial - /export/home/gdbgui/toolshg" thread that's constantly running and grabbing a lock. If I front the IDE causing repaints then the MercurialView thread starts waiting on it ... but these don't seem very long lasting blockages ... the locks goes away in subsequent snapshot. Can you elaborate on what you said: "people used to have .hg in their home folder which results in complete scan"? You mean a repository in their home folder? You mean Hg will scan siblings of the repository? In the various snapshots the AWT eventq is doing all kinds of different things not always related to DiskMapTurboProvider. I'm using 6.5.1 and will attempt to swith to 6.7 and see what happens there and try and use the profile me nwo button.
> people used to have .hg in their home folder which results in complete scan We came across a few situations when some users had a .hg in their ~/ folder (don't know the reason however). Then the mercurial plugin scanned all the files in the ~/... Most of the files under ~/ were unknown to hg (meaning they had a '? status' in 'hg status'), because the of course had never been committed, but our plugin recognized them as 'Locally New' and kept information about them in its cache. So eventually the cache grew into MBs of its size and every access was painfully slow. The cache should usually be max tens of KBs.
DiskMapTurboProvider (and the persistent cache) is no longer used by mercurial in 6.8. Status calls should be much faster now and AWT should not be blocked by mercurial.
I was working couple of days with the netbeans sources hg repository (in 6.8) and never run into described troubles. Executing Mercurial>Status took maximally 10s (in most cases even less). I am marking this issue as VERIFIED now. Of course it would be great to hear from the reporter (ivan) - are you experiencing better performance in 6.8 in this case? Or does the problem persist? Thanks in advance
(I mean in upcoming 6.8 beta / dev builds)
My mercurial cache has been "under control" since I filed this IZ and then cleaned it up. I've been using 6.7 and haven't had problems with slow status. The giant cache that was causing me trouble looks like a one-time pathology and I'm not sure I can reproduce it to verify performance. I'll consider using 6.8B when it comes out.