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.
Using a custom build of 040810 on 1.5.0 b62, I opened the core module and began moving the selection (with arrow keys) up and down its subdirs in the Files tab. This was unexpectedly slow, which made some sense in that the main window title was being updated as selection moved into subprojects. However after moving up and down a couple of times, it got much slower and eventually the IDE froze completely. I took a number of thread dumps which mostly implicate vcscore. Oddly, the Favorites tab is also involved; I don't know why, since it was open only in sliding mode; I was using the Files tab. I had nb_all mounted as a CVS filesystem, but had turned off display of status info in the display name of nodes, by editing the annotation pattern to exclude the status field.
Created attachment 16764 [details] Thread dumps (GZIPped)
Start 040810 (custom) on a fresh user dir; 1.4.2_04. Close welcome screen. Open Versioning Manager; add /space/src/nb_all. Edit it and under Properties, click "..." on Annotation Pattern. Select "If defined: status", Delete. Apply Changes (this is NOT done automatically if you just press OK, note!), then OK. Close customizer and versioning manager. Close Versioning tab. Open /space/src/nb_all/core (as main project, no required projects). Wait for classpath scanning to finish. Switch to Files tab. Expand "Core" node; do not even move selection. Painting of IDE window is initially very slow; soon freezes completely (grey screen). Have to kill IDE. Will attach log & thread dumps. No involvement from favorites tab this time.
Created attachment 16765 [details] New log & thread dumps (GZIPped)
No such freeze is reproducible when not using CVS. If I make a CVS mount but set Annotation Pattern to just "${fileName}", can still reproduce after a while. In this case DataNode.getOpenedIcon is involved in some stack traces, which is to be expected (need to annotate icon); disturbingly, DataNode.getDisplayName is involved in others, i.e. the VCS support is calculating things it will not even need! E.g.: [...] at org.netbeans.modules.vcscore.caching.RefreshCommandSupport.getStatusAnnotation(RefreshCommandSupport.java:413) at org.netbeans.modules.vcscore.VcsFileSystem.annotateName(VcsFileSystem.java:2605) at org.netbeans.modules.masterfs.MasterFileSystem$StatusImpl.annotateName(MasterFileSystem.java:275) at org.openide.loaders.DataNode.getDisplayName(DataNode.java:171) [...] Also in getHtmlDisplayName -> annotateNameHtml. May be considered P1 in that it effectively prevents me from using the CVS support in NB at all, as far as I can tell.
In the first bunch of thread dumps a lot of threads ends in org.openide.filesystems.FileUtil.normalizeFile(). This was added assure a unique File. Also it seems that the last fix of issue #41012 is involved (it's already reverted now), since it's apparent the that cache objects are being read from disk again and again. We will rework that last fix, hopefully without these side-effects. The second set of thread dumps seems to be similar. I do not see any deadlock. The annotation mechanism does not check the pattern before it asks the cache for status info. Therefore the performance is the same regardless of whether the status annotation is displayed or not. This can be fixed as a separate issue. This issue is IMO solved by the rollback of the last commit to cache system (issue #47112).
IMO the root of the problem is not in VCS, but in the fact that someone is asking for the display name again and again as you're moving in the nodes hierarchy.
The interpretation of "${fileName}" annotation pattern optimized, the caching framework is not touched in this case: /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/RefreshCommandSupport.java,v <-- RefreshCommandSupport.java new revision: 1.31; previous revision: 1.30 This will not really help, since annotateIcon has to consult the cache anyway. Marking as fixed, after the rollback it should work like before.