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.

Bug 183483

Summary: Invoking insert-break took 473674 ms.
Product: javaee Reporter: Exceptions Reporter <exceptions_reporter>
Component: JSPAssignee: Tomasz Slota <tslota>
Status: RESOLVED FIXED    
Severity: normal CC: mfukala, mmetelka
Priority: P3 Keywords: PERFORMANCE
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter: 166749
Attachments: nps snapshot

Description Exceptions Reporter 2010-04-05 12:48:48 UTC
Build: NetBeans IDE 6.8 (Build 200912041610)
VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06
OS: Windows Vista
Maximum slowness yet reported was 473674 ms, average is 291560
Comment 1 Exceptions Reporter 2010-04-05 12:48:56 UTC
Created attachment 96681 [details]
nps snapshot
Comment 2 Marek Fukala 2010-05-06 12:26:48 UTC
It's hard to say what goes on. The AWT thread is blocked by the body of the  IndentImpl.indentLock() method, likely by the wait() method on line 139. 

It looks like some other (non-AWT) thread called the indentLock() and then the AWT call from BaseKit$InsertBreakAction to the method happened. 

The snapshot indicates there is the scanning in progress so it's possible that the other thread after acquiring the lock waits for some parsing.api stuff and is blocked for long time.

Who and why in non-AWT thread called the indentLock() method is a mystery to me. The snapshot may also indicate some of the callstacks incorrectly so maybe the problem is in different place.

I suspected IndentImpl.indentLock():147 which calls taskHandler.lock() which then locks all the involved indenters, but at first the call should be visible in the snapshot and for the second at least in current 6.9 trunk build none of the indenters does any locking (none of them have an extraLock).
Comment 3 Marek Fukala 2010-05-12 11:28:48 UTC
Since there just two older reports of this kind I am closing the issue as already fixed. We'll see if it appears again.