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 200909010201) VM: Java HotSpot(TM) 64-Bit Server VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Linux, 2.6.28-15-generic, amd64 User Comments: fzamboj: I disabled breakpoint on method start and right away enabled a breakpoint on code in that method. All was done by toggling the bar with line numbers not in breakpoint view. Maximum slowness yet reported was 20825 ms, average is 20825
Created attachment 87633 [details] nps snapshot
This is because parsing is called from AWT. It's also illustrated by following warnings printed into messages.log: WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.debugger.jpda.projects.EditorContextImpl.getCurrentElement(EditorContextImpl.java:1782) WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.debugger.jpda.projects.EditorContextImpl.getCurrentMethodDeclaration(EditorContextImpl.java:911)
Build: NetBeans IDE Dev (Build 090928) VM: Java HotSpot(TM) Client VM, 14.1-b02, Java(TM) SE Runtime Environment, 1.6.0_15-b03 OS: Linux, 2.6.28-15-generic, i386 User Comments: Trying to remove a breakpoint by clicking on its icon. Maximum slowness yet reported was 45086 ms, average is 32955
Created attachment 88455 [details] nps snapshot
Time (CPU) shows 14.3ms, which is O.K. for AWT. There is absolutely no reason for ReentrantLock.tryLock() to take 20 seconds. The code should behave fine when called from AWT.
I've just seen: http://statistics.netbeans.org/exceptions/exception.do?id=290654 - 8s is way too much to justify "wontfix" I guess.
?? 8s ? Time (CPU) for AWT thread is 234ms. Resolving back as WONTFIX.
The CPU time is small because the thread is blocked waiting for something else. (In my snapshot the CPU is being consumed ultimately by the project system finding classpaths, inside the JPDAReload Ant task.) The problem is calling JavaSource.runWhenScanFinished, a potentially blocking method, from EQ. Probably ToggleMethodFieldBreakpointAction.submitFieldOrMethodBreakpoint should run asynch, or at least use the new ProgressUtils.runOffEventDispatchThread.
1) There is no reason why java.util.concurrent.locks.ReentrantLock.tryLock() would sit there for 45 seconds! This method should return immediately. In this case it looks like tryLock(100, TimeUnit.MILLISECONDS) is called, but this still does not justify the 45 seconds! Because of that I considered the dump to be broken. 2) JavaSource.runWhenScanFinished() returns Future. Therefore I do not think it should be blocking anything. Therefore moving to Java, I do not think I can do anything with these items.
I see two issues here: -debugger calls runWhenScanFinished, which, in case no scan is running, blocks (behaves the same as runUserActionTask). -some queries are very, very slow in the IDE. For example, in Jesse's dump, apisupport.project.queries.ClassPathProviderImpl.findClassPath takes more than 41s! In Filip's snapshot the UpdateTrackingFileOwnerQuery.getOwner takes more than 12 seconds! So when the user does an action, the action will take at least 41s/12s to complete. Even if there would be a progress, the user wants the action to be done, not to look at the progress. What is the inevitable reason why apisupport.project has to be so incredibly slow?
The problem is in the debugger calling java parser in the AWT thread. The JS.runWhenScanFinished javadoc says: <cite> Performs the given task when the scan finished. When no background scan is running it performs the given task synchronously. When the background scan is active it queues the given task and returns, the task is performed when the background scan completes by the thread doing the background scan. </cite> When no background scan is active it behaves in the same way as the JS.runUserActionTask. When there is already a user action task running it blocks until it is done and that this task is executed. The user action tasks are rather fast, the problem in this case is that the active user task ended in the slow apisupport project.
After discussion with Tomas,moving to apisupport. User action tasks should be rather fast, but tasks in apisupport are quite slow and all other tasks must wait for them....
Build: NetBeans IDE 6.8 Beta (Build 200910212001) VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Linux, 2.6.27-9-generic, i386 User Comments: Code Sense drop down Maximum slowness yet reported was 53047 ms, average is 17359
Created attachment 90936 [details] nps snapshot
This issue already has 12 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=158472
Probably a dupe of the issue to rewrite module scanning to be fully incremental.
Created attachment 92613 [details] nps snapshot I copied same code from old class to new one.
Not clear what the common issue in these snapshots is, or what the slow "tasks" in apisupport are. Bug #173109 made module list loading a lot faster, but I don't see that being invoked.