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.
Summary: | rewrite lazy menu loading | ||
---|---|---|---|
Product: | platform | Reporter: | greggwon <greggwon> |
Component: | Window System | Assignee: | Stanislav Aubrecht <saubrecht> |
Status: | NEW --- | ||
Severity: | normal | CC: | anebuzelsky, sreimers |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows Vista | ||
Issue Type: | TASK | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 208734 |
Description
greggwon
2010-10-28 22:51:58 UTC
i agree that the lazy menu implementation needs a rewrite but it'll have to wait till the next release. FYI, I had to do some dirty tricks to avoid classloading in the EDT in mobility which, while ugly, are applicable here: In order to meet responsiveness requirements, what I ended up doing is loading classes from a textual list of classes on a low-priority background thread which is started when the first piece of relevant UI is shown (I think this was in the new mobile project wizard). Not nice, as the list needs to be maintained over time (easy enough to turn on -verbose:gc to get a list of culprits, though). However, it's not 100% obvious that classloading per-se is the issue here, as opposed to two threads in the same VM trying to do I/O at the same time (which is clearly happening). File I/O from Java on Windows in particular is much more serialized than on Unix - basically, the calling thread can and will be put to sleep by the OS and queued to be serviced by the filesystem driver. In the thread dump above there are no locks shared between Refresh-After-WindowActivated and AWT-EventQueue-1, but it's very, very likely (we've seen this before) that AWT-EventQueue-1 is blocked in native OS code waiting for Refresh-After-WindowActivated. I don't think it is practical to try and avoid any classloading in the EDT - the design of Java classloading and Swing makes that a near impossibility. Possibly this particular issue could be fixed by reducing I/O *contention*. I know that Refresh-After-WindowActivated uses an AWTEventListener and a reschedulable RequestProcessor.Task which runs its background task on a delay after the main window is reactivated. Possibly the AWTEventListener could be made smarter by increasing the delay before refreshing happens after window activation, and resetting the delay (to delay the task further) if any non mouse-motion InputEvent occurs during the quiet interval after window activation. That's certainly not a silver bullet - if a menu is shown and the refresh task is running when a submenu needs to be shown you can have the same problem (but submenus are smaller, and the odds of this happening frequently are at least lower). But it would decrease the likelihood in-VM cross-thread I/O contention by keeping the refresh task from running at exactly the same time I/O in the EDT is very likely to be necessary. My main point is that the problem here is not classloading per se, but I/O contention - it's not necessarily a big deal that classloading is done on the EDT, the problem is that it is happening while another thread tries to do very heavy I/O. And that the blockage is at the OS level (can't prove it, just have seen this pattern of hang many times and it is Windows-specific). For some background on the Windows file I/O issue, see http://netbeans.org/bugzilla/show_bug.cgi?id=65135#c37 The main issue, is that no matter what the actual work done, if it does not involve exactly the tasks of "rendering" or "assembling" the components on the screen, it is not work that belongs on the EDT. The EDT is not a work thread, it is a single purpose thread which needs to be used for specific tasks so that the overall user interface experience can be performant. I think that the whole issue here perhaps lies in the details of whether these late bound menus are actually working the correct way. From many perspectives, netbeans uses an inverted responsibility tree. Instead of requiring the modules to say "this is the state of the world", netbeans is always going around asking "what is the state of the world now". This ends up wasting a lot of CPU time and thus impacts the users experience (for example the on going posts to the list about "Why is netbeans scanning again" and "Why is netbeans doing X when I asked for Y"). The user interface really needs to be a "static" view that changes over time, rather than a "dynamic" view which netbeans discovers from moment to moment. The fact that there are so many reported issues (I know that I've reported several) about how EDT use is causing the UI to not be responsive and from developers having problems with "in EDT" or "out of EDT" questions, seems to me, to indicate that there are some responsibilities that are inverted, or deferred till too late, and so large amounts of work are being needed in the EDT. It seems that there are some opportunities to look at a different perspective of how the same, or similar features might be provided without the EDT being responsible for any discovery of what needs to be rendered/displayed. Another part of this issue might be that with CMSEnableClassUnloading in effect, many parts of the IDE might actually be unloaded and this could create additional delays as things are reloaded when the menu system is needed, perhaps? switching issue type to 'task' as this means the complete rewrite of the main menu bar. |