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.
Build: NetBeans IDE Dev (Build nbms-and-javadoc-3954-on-090919) VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Windows XP, 5.1, x86 User Comments: GUEST: clicked on the "Web Services" triangle to open list GUEST: opening Tools menu in freshly loaded netbeans GUEST: NetBeans IDE was starting Maximum slowness yet reported was 6516 ms, average is 4022
Created attachment 88181 [details] nps snapshot
This issue already has 8 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=157706
Suspicious method: org.openide.awt.DynaMenuModel.loadSubmenu It calls org.netbeans.modules.refactoring.api.impl.ActionsImplementationFactory.canFindUsages() which uses lookup and it reads resources from jar files. I don't know how it can be improved.
Contention of global monitor fixed in MetaInfServicesLookup in revision core-main#90ca3b84c07f - still many other things to fix (this was at most 0.5s from those ~3s).
Integrated into 'main-golden', will be available in build *200909251401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/90ca3b84c07f User: Jaroslav Tulach <jtulach@netbeans.org> Log: Partial fix for #172865: Don't hold global lock while seeking for getResources(...). That is expensive operation and can take long time. No need to block other threads.
Let's talk about: http://statistics.netbeans.org/exceptions/exception.do?id=270971 I can see that the AWT thread is blocked few times in FileObjectFactory.getFileObject() method (four times for ~2s). Why, what is so expensive on checking one fileobject? Well, probably nothing, but it needs Mutex.readAccess and that is not available. There "JavaFX Annotatator" thread which calls getChildren(). This call accesses internal cache under the write lock and also does a lot of disk I/O (to find out if a File is plain file or directory). Global locks are bad. They cannot be hold while doing expensive computation. Please move the I/O outside of the write lock.
This issue already has 11 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=157706
If I move I/O operations in ChildrenSupport.rescanChildren out of the write lock, I am afraid it allows two threads do the I/O simultaneously. It would be even worse. Anyway first or second thread sooner or later has to wait for the I/O. If it is an issue, the caller of the Filesystems API should move it outside of the AWT thread.
The problem is not to use lock, the problem is that there is one lock for all fileobjects. Thus two different fileobjects are mutually influenced. This is similar to bug 172260, the fix could also be similar - e.g. create a future under the big lock and fill its content afterwards.
This issue already has 13 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=157706
Fixed. Global Mutex is not used for synchronization anymore. A new Mutex is created for every ChildrenCache instance and used for synchronization. core-main #2c9db5489061
Integrated into 'main-golden', will be available in build *200910150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2c9db5489061 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #172865 - Create local Mutex instance in every ChildrenCache and use it for synchronization. Otherwise global Mutex blocked two threads even if they wanted to approach children of two different FolderObj.