Community
Participate
Working Groups
Created attachment 80136 [details] [file] stack trace while paused in the debugger Version: 3.4.0 Build id: I20071010-1200 Context: debugging a workbench running against a large workspace (1600+ plug-ins / projects) in which the target platform also has 1600+ plug-ins / projects. I have 2 versions of the Sun 1.6 JRE located in 2 directories: 1.6.0 and 1.6.0_05 The default JRE used for my debug session was uses the 1.6.0 directory. Scenario: - rename directory 1.6.0 to 1.6.0_03 - rename directory 1.6.0_05 to 1.6.0 - launch the debug session (targeting the large workspace) - once UI becomes visible, go to the Progress View to monitor the Initialization of the Java Tooling startup job - after some time, the UI becomes unusable, as of it entered a loop. - paused the Main thread in the debugger, and found that the PackageExplorerContentProvider was busy trying to refresh the treeViewer. (I'll attach the stack trace) After performing some code instrumentation, found that: PackageExplorerContentProvider.runPendingUpdates() line: 161 was busy running 10740 runnables, each of it having only a single entry per toRefresh list. The problem is that each runnable seems to refresh the selection of the treeviewer, 10 000+ times. May be it would be possible to group the 10 000+ updates and update the tree only once. I agree you don't change your JRE every hour, but even only once, it's can become really painfull not to be able to access your workbench.
We need to find out where the refresh requests come from. Could be either from Java element deltas or from decorator refreshes. Could you maybe turn off all decorators on 'Labels Decorator' preference page and see if this makes a difference.
(In reply to comment #1) with all decorator turned off, same issue. Sounds like the refresh is stating once the Java Tooling initialization job reaches 59% (refreshing external archives) This is the dummy search performed during initialization in JavaCore#initializeAfterLoad operation.
(In reply to comment #2) also not that the init of Java Tooling job remains stucked at 59% until the refresh has completed...
I debugged the given scenario: The VM changes and each library in the VM has content change. The delta contains around 10 changes per project, and each of them is refreshed. If you have 1600 plugins, that will result in 16000 refreshes - All refreshes are bundled, only one syncExec is sent out - The JFace viewer code does not really perform a refresh as all project are collapsed after startup and no archive is shown yet Given the two last observations, its difficult to improve the situation - All the archives have changes, according to the delta, so there's no other choice than to refresh them. Refresh the parent (project) can be much more expensive as it would refresh all other archives as well.
.
