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 160377

Summary: EQ frozen loading form
Product: guibuilder Reporter: Jesse Glick <jglick>
Component: CodeAssignee: issues@guibuilder <issues>
Status: RESOLVED FIXED    
Severity: blocker CC: adam_myatt, armandojaga, exceptions_reporter, hedefalk, hmichel, jis, komealy, mklaehn, mschneider, necipakif, ravilan, ringerc, roger_rf, Wilson_Filho, xpilot
Priority: P2 Keywords: PERFORMANCE, THREAD
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Attachments: Thread dump
nps snapshot
nps snapshot

Description Jesse Glick 2009-03-16 16:28:32 UTC
I opened a bunch of files, apparently including at least one form, using --open CLI. The IDE is taking several minutes
to scan all the new modules (expected). But the UI is frozen this whole time. It seems that
GandalfPersistenceManager.getSuperClassName blocks on parsing.
Comment 1 Jesse Glick 2009-03-16 16:29:43 UTC
Created attachment 78242 [details]
Thread dump
Comment 2 Jan Stola 2009-04-06 16:52:23 UTC
*** Issue 161837 has been marked as a duplicate of this issue. ***
Comment 3 Jan Stola 2009-10-07 14:35:53 UTC
*** Issue 172175 has been marked as a duplicate of this issue. ***
Comment 4 Jan Stola 2009-10-07 14:36:31 UTC
*** Issue 171132 has been marked as a duplicate of this issue. ***
Comment 5 Jan Stola 2009-10-07 14:37:02 UTC
*** Issue 171920 has been marked as a duplicate of this issue. ***
Comment 6 Jan Stola 2009-10-07 14:38:54 UTC
*** Issue 172064 has been marked as a duplicate of this issue. ***
Comment 7 Jan Stola 2009-10-07 14:44:16 UTC
*** Issue 170195 has been marked as a duplicate of this issue. ***
Comment 8 Jan Stola 2009-10-07 14:44:26 UTC
*** Issue 169210 has been marked as a duplicate of this issue. ***
Comment 9 Jan Stola 2009-10-07 15:08:44 UTC
*** Issue 171461 has been marked as a duplicate of this issue. ***
Comment 10 Jan Stola 2009-10-08 08:01:54 UTC
*** Issue 174022 has been marked as a duplicate of this issue. ***
Comment 11 Jan Stola 2009-10-09 07:27:42 UTC
*** Issue 174139 has been marked as a duplicate of this issue. ***
Comment 12 Jan Stola 2009-10-09 07:31:37 UTC
*** Issue 174142 has been marked as a duplicate of this issue. ***
Comment 13 Jan Stola 2009-10-09 15:17:46 UTC
*** Issue 174234 has been marked as a duplicate of this issue. ***
Comment 14 Jan Stola 2009-10-09 16:50:01 UTC
*** Issue 174232 has been marked as a duplicate of this issue. ***
Comment 15 Jan Stola 2009-10-21 14:25:53 UTC
*** Issue 172055 has been marked as a duplicate of this issue. ***
Comment 16 Jan Stola 2009-10-26 11:56:02 UTC
*** Issue 175412 has been marked as a duplicate of this issue. ***
Comment 17 Jiri Sedlacek 2009-11-05 19:01:13 UTC
http://statistics.netbeans.org/analytics/detail.do?id=159752 contains 42 duplicates, maximum slowness 86718 ms - really
just a P3?
Comment 18 Chiana 2009-11-10 22:40:16 UTC
Created attachment 90760 [details]
nps snapshot
Comment 19 Exceptions Reporter 2009-11-10 22:40:23 UTC
This issue already has 201 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=154265
Comment 20 Tomas Pavek 2009-11-12 10:45:13 UTC
I don't think this is a stopper for release. The behavior is known, we have it in NetBeans for several releases, and haven't seen huge complaints about it. The GUI Builder has a special reason why it needs to open the GUI forms in AWT thread. Also it shows the loading message in the designer area, in status bar, there is wait mouse cursor - so it is not locked by surprise. For times less then 10s I think it is not a big problem.

Of course the slowness detector reacts on blocked AWT thread. Because this is quite frequently used feature, we've got many reports of slowness. But I think just a minority of real form openings happen in the situation when waiting for scanning that is just under way - then the UI can be blocked for a longer time. (In fact it often works even during scanning.)

Overall we can't make this faster, can't do anything if java infrastructure need time for parsing. What should be done is to have the java source access run at the beginning of the open operation, out of AWT thread, allowing to cancel the operation (before it really starts loading the GUI which needs to run in AWT). Such a fix is unfortunately not straightforward and rather risky at this time of release cycle.
Comment 21 Jan Stola 2009-11-26 06:20:27 UTC
*** Bug 177195 has been marked as a duplicate of this bug. ***
Comment 22 Jan Stola 2009-12-01 07:10:22 UTC
*** Bug 177813 has been marked as a duplicate of this bug. ***
Comment 23 Jan Stola 2009-12-04 02:59:37 UTC
*** Bug 178068 has been marked as a duplicate of this bug. ***
Comment 24 Jan Stola 2010-01-11 03:36:45 UTC
*** Bug 179321 has been marked as a duplicate of this bug. ***
Comment 25 mschneider 2010-01-11 08:08:09 UTC
Created attachment 93186 [details]
nps snapshot
Comment 26 Tomas Pavek 2010-01-22 06:03:25 UTC
Implemented the described fix. Now the superclass of opening form is checked at the beginning, out of AWT thread - if that needs to wait on unfinished java scanning, the IDE is not blocked, it's even possible to close the form (in state when it displays "Loading") if don't want to wait.

The second part of form loading is still done in AWT thread, I see no way to do it otherwise due to manipulation with L&F settings. This may still block UI for some time for large forms.

http://hg.netbeans.org/cdev/rev/c2a96cfc3295
Comment 27 Michel Graciano 2010-01-22 08:29:15 UTC
Thanks Tomas.
Comment 28 Quality Engineering 2010-01-24 08:48:55 UTC
Integrated into 'main-golden', will be available in build *201001240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/c2a96cfc3295
User: Tomas Pavek <tpavek@netbeans.org>
Log: #160377: don't wait on scanning during form opening in AWT thread
Comment 29 Tomas Pavek 2010-03-12 07:23:10 UTC
*** Bug 181732 has been marked as a duplicate of this bug. ***
Comment 30 Jan Stola 2010-03-16 12:25:19 UTC
*** Bug 182026 has been marked as a duplicate of this bug. ***
Comment 31 Jan Stola 2010-03-31 11:12:05 UTC
*** Bug 183229 has been marked as a duplicate of this bug. ***
Comment 32 Jan Stola 2010-04-07 12:45:58 UTC
*** Bug 183465 has been marked as a duplicate of this bug. ***
Comment 33 Jan Stola 2010-04-14 10:05:54 UTC
*** Bug 177860 has been marked as a duplicate of this bug. ***
Comment 34 Jan Stola 2010-05-10 15:22:41 UTC
*** Bug 185621 has been marked as a duplicate of this bug. ***
Comment 35 Jan Stola 2010-05-14 10:04:43 UTC
*** Bug 186133 has been marked as a duplicate of this bug. ***