Bug 92106

Summary:

Memory leak in PerformanceStats

Product:

[Eclipse Project] Platform

Reporter:

Markus Keller <markus.kell.r>

Component:

Runtime

Assignee:

John Arthorne <john.arthorne>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

john.arthorne, Tod_Creasey

Version:

3.1

Keywords:

performance

Target Milestone:

3.1 M7

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Screenshot	none

Description Markus Keller

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

2005-04-20 12:30:40 EDT

Created attachment 20136 [details]
Screenshot

Comment 2 Kim Horne

2005-04-20 12:49:16 EDT

Oh I'd love to resolve this IRONIC.  :)

Comment 3 John Arthorne

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

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

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!