Bug 92106 - Memory leak in PerformanceStats
Summary: Memory leak in PerformanceStats
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Runtime (show other bugs)
Version: 3.1   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: 3.1 M7   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2005-04-20 12:29 EDT by Markus Keller CLA
Modified: 2005-04-21 11:17 EDT (History)
2 users (show)

See Also:


Attachments
Screenshot (12.76 KB, image/png)
2005-04-20 12:30 EDT, Markus Keller CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2005-04-20 12:29:53 EDT
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.
Comment 1 Markus Keller CLA 2005-04-20 12:30:40 EDT
Created attachment 20136 [details]
Screenshot
Comment 2 Kim Horne CLA 2005-04-20 12:49:16 EDT
Oh I'd love to resolve this IRONIC.  :)
Comment 3 John Arthorne CLA 2005-04-20 18:36:23 EDT
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.
Comment 4 Mike Wilson CLA 2005-04-21 09:55:54 EDT
On the mac, at least, the performance view fails the "view activation" test quite frequently. This does 
seem rather bogus.
Comment 5 John Arthorne CLA 2005-04-21 11:17:09 EDT
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!