Community
Participate
Working Groups
I20050419-1200 I started with the performance debug options from the .options file shipped with eclipse. From looking at a YourKit snapshot, I'd say that the performance view leaks CompilationUnitEditors in the blame field of PerfomanceStats saved in the data pointer of TableItems.
Created attachment 20136 [details] Screenshot
Oh I'd love to resolve this IRONIC. :)
Stats are also held onto at the runtime level (PerformanceStats.statMap). To avoid this we would need to completely avoid holding blame objects. Note that in the release version, stats will be turned off and the performance view will be removed, so this isn't a major problem.
On the mac, at least, the performance view fails the "view activation" test quite frequently. This does seem rather bogus.
Fixed. Stats objects no longer hold onto the blame object directly. They now hold only a string representation of the object's class, and the id of the blame's plugin. This is all the information we need from the blame object. That was quite a memory leak!