Bug 141517 - [JUnit] High memory consumption from JUnit history
Summary: [JUnit] High memory consumption from JUnit history
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M7   Edit
Assignee: Markus Keller CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2006-05-12 06:48 EDT by Philipe Mulet CLA
Modified: 2007-03-28 10:43 EDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2006-05-12 06:48:34 EDT
3.2 - I20060505-1306

I am running with -Xmx512M on the command line; and noticed the heap size monitor to say 493M of 512M allocated, which is way more than in average for my self-hosting workspace (usually cruising at 240M).

Using yourkit 5.5, I got a memory dump, which shows 50M are held by the JUnit history. This is not a leak per se, since I flushed history and the memory got claimed back correctly (still 50M for junit history is huge... entire JavaModel only takes 17M).
Comment 1 Philipe Mulet CLA 2006-05-12 06:49:30 EDT
I had no terminated launch left in debugger.
Comment 2 Philipe Mulet CLA 2006-05-12 07:03:47 EDT
Dump is too big to attach. Sent it to Martin (62M compressed).
Comment 3 Martin Aeschlimann CLA 2006-05-12 09:04:48 EDT
Full model size is 46.6.

The trace contains 12 history entries with an average of 5500 test cases each.
-> total of 66'000 test cases held for 26.MB
Overhead per test case is only small, main part are strings for the name and strings for the stacktraces.
Each history entry keeps a hash lookup to all entries as well as a representation as tree. The arrays for these take the rest of the memory.

As the biggest amount of memory is used in string, the solution would be to persist history entries when they are not visible and not running.
We have to tackle that after 3.2.
Comment 4 Philipe Mulet CLA 2006-05-12 12:34:09 EDT
I would imagine retaining only fine grain data of failures. The rest doesn't reall y matter (mostly the suite name). Assuming there are little failures in general, it should reduce the footprint.
Comment 5 Philipe Mulet CLA 2007-03-19 12:35:00 EDT
This one still appears to be a big memory consumer. Somewhat like a leak in essence.

Can we do something for 3.3, before it gets too late ?
Comment 6 Markus Keller CLA 2007-03-20 11:06:01 EDT
I'm working on this, but unfortunately the implementation was not stable enough to be released for M6.
Comment 7 Markus Keller CLA 2007-03-28 10:43:36 EDT
Fixed in HEAD. Test runs that are not active and that are not shown in a JUnit view are now swapped out to disk.