Bug 182695 - Component creation off EDT during startup
Component creation off EDT during startup
Status: REOPENED
Product: platform
Classification: Unclassified
Component: -- Other --
6.x
All All
: P3 (vote)
: TBD
Assigned To: issues@platform
issues@platform
: PERFORMANCE, RANDOM, THREAD, UMBRELLA
Depends on: 182696 182697 182698
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-24 17:06 UTC by _ tboudreau
Modified: 2010-03-25 19:32 UTC (History)
0 users

See Also:
Issue Type: TASK
:


Attachments
Thread dump (21.72 KB, text/plain)
2010-03-24 17:06 UTC, _ tboudreau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2010-03-24 17:06:04 UTC
Created attachment 95709 [details]
Thread dump

Start NetBeans on an existing userdir.  As soon as the main window opens, click the Tools menu, then click Plugins.

This needs to be fixed in several places - see the attached thread dump - there are 4 (!!!) threads all trying to manipulate Swing components - which should only be done on the AWT event thread.  One of them is in Apple's JDK, so we cannot do anything about it.  The rest are all bugs we can and must fix.

I will make this an umbrella bug and file individual bugs for the threads in question.
Comment 1 _ tboudreau 2010-03-24 17:21:22 UTC
Adding performance keyword.  Even if it does not cause a deadlock, any user interaction that the UI responds to (mouse click, keypress) will be blocked until these other threads have released the AWT tree lock.  Even if it were safe to take the AWT tree lock from a background thread, the GUI cannot respond while it is held, so such code will cause a responsiveness/liveness issue.
Comment 2 Stanislav Aubrecht 2010-03-25 10:42:25 UTC

*** This bug has been marked as a duplicate of bug 167401 ***
Comment 3 Stanislav Aubrecht 2010-03-25 10:48:14 UTC
we'd have to rewrite a huge part of the IDE to move all component creation to EDT. creating components off the event dispatch thread doesn't cause any problems AFAIK - except for nimbus look & feel (#174500).

i don't think it's wise to make such changes just a few days before release
Comment 4 _ tboudreau 2010-03-25 19:31:33 UTC
I will downgrade this to P3, but reopening as an umbrella bug until bug 182698 is fixed.

This is not a duplicate of bug 167401. Bug 167401 was closed because this problem was supposedly fixed in an update to Mac OS 10.5.  I encountered this deadlock on Apple's JDK 1.6.0_15 on Mac OS 10.6.2. Either Apple had a regression, or it was never actually fixed.

Even if the Apple AppKit thread accessing Swing components were fixed, that just means one deadlock we *know about* won't happen.  If we are constructing components on random threads, deadlock is possible, and GUI responsiveness will be affected, no matter what.

And especially if we know Apple's toolkit is still accessing Swing components from its own non-EDT thread (and we do know that), the less threads *we* have breaking the threading rules, the lower the chance that their bug will cause a complex deadlock.

I don't think we have to move *all* component creation to the EDT *right now* - but where we know about it and can fix it, we certainly should.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo