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 200908050201) VM: Java HotSpot(TM) 64-Bit Server VM, 11.3-b02-83, Java(TM) SE Runtime Environment, 1.6.0_13-b03-211 OS: Mac OS X, 10.5.7, x86_64 Maximum slowness yet reported was 23144 ms, average is 23144
Created attachment 85844 [details] nps snapshot
Looks like there is a problem with JarClassLoader. I am not sure what to do to fix this issue, but I'd suggest to add more detailed logging into the classloader. Maybe it will give us better understanding what module is causing the problem, what class is being loaded and whether it is really one class or multiple ones.
Mostly in ZipFile.read, a bit in ClassLoader.defineClass1. There are at least a few classes being loaded but it is possible the slowness detector cannot accurately measure native methods like this. Probably a cold disk issue, nothing to do.
Please add Level.INFO logging when loading of a class takes longer than 1s.
Extra logging of the type you suggest would be pointless in this case. You can see from the profiler snapshot what is being loaded - just a few classes related to GroupLayout - and where it is frozen - ZipFile.read. The other active thread is running the <makenbm> target which is performing a DirectoryScanner traversal, i.e. grabbing tons of inodes. Looks like the OS is simply not preempting very well, but that's not unusual. DTrace analysis might explain better why preemption does not work but it is unlikely that would point to any concrete improvement we could make.
*** Issue 170121 has been marked as a duplicate of this issue. ***