Community
Participate
Working Groups
Version: 3.3.0 Build id: N20070415-0010 J2RE 5.0 IBM J9 2.3 Windows XP x86-32 build j9vmwi3223-20070201 Found while verifying fix for bug 181900. Test scenario: same as for bug 181900, open/close org.eclipse.update.configurator project in the monster workspace. the open / close dialog shows up 5 sec but then, a background job takes 100% of the CPU, and the workstation becomes barely usable until this background job has completed (sometime 3 minutes !) Taking traces and snapshots leads to a package explorer issue, while trying to update the projects tree. To be attached files: 1 - jvm dumps 2 - Yourkit snapshots 2 - screen shot
Created attachment 63873 [details] jvm dumps
Created attachment 63874 [details] Yourkit CPU snapshot (on close project)
Created attachment 63875 [details] Yourkit CPU snapshot (on open project)
Created attachment 63878 [details] package explorer Note the 2 identical items in the tree
The filter updater is a resource listener that looks for changes of the description of projects. That can be added/removed natures, changed project location, changed project references or a name change. If it detects one of these, it will refresh the full view, which takes all the time you're observing. Two problems: 1. I coudn't reproduce the stacktraces as shown in the dumps: Open/close is not a description change. Can you maybe set a breakpoint in jdt/ui's FilterUpdater line 46 and maybe find out why the description changed 2. Why do we have the filter updater? I don't know what description change could be interesting. Add/remove nature would result in a Java element deltas, project location and references are uninteresting, changed name will be in normal deltas as well. Dani do you have an idea?
I found the reason for comment 5 issue 1.: If a project is referenced through a classpath container the compiler adds a dynamic reference which is removed for closed projects again. issue 2. seems more interesting to me. I believe we could risk to remove that updater. I don't see which of our filters depends on the refresh.
Created attachment 63887 [details] screen shot Closing project: stopped at line 46 in FilterUpdater
re 2) this is needed because some filters only apply for certain projects, e.g. if a JDT projects becomes a PDE project. Dropping will cause inconsistencies.
Do you knwo which filters? the one we contribute, do not depend if an additional nature is added. If other contributions do this, then they probably should be responsible for updating. The problem is, the 'description' changes happen quite often because of changing dynamic project references.
I have to checke each filter. Adding Dirk, since he added the filter updater.
In the SDK the only filter that would get broken is the BinaryProjectFilter from PDE but other clients that contribute a similar filter (e.g. WTP) might then suffer from the change as well.
A long time ago ;-). I don't remember the problem that got fixed by adding the updater.
fix released > 20070418 The fix tests if the project description delta really results in different filter behavior. Only if this is the case, the package explorer is refreshed.
(In reply to comment #6) > I found the reason for comment 5 issue 1.: If a project is referenced through a > classpath container the compiler adds a dynamic reference which is removed for > closed projects again. > Actually when a project is closed, JDT/Core doesn't remove the reference directly. What you're seeing is expected: when the project is closed, PDE removes the project reference from the Plug-in Dependencies container, and calls JDT/Core to update this container. As a consequence, an IResourceDelta#DESCRIPTION is triggered.
