JDK-4208524 : Small SwingMark Memory Leak
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.2.2
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-02-03
  • Updated: 2013-11-01
  • Resolved: 1999-04-18
Related Reports
Duplicate :  
Relates :  
Description
Running the SwingMark benchmark harness repeatedly in the same VM shows there is a small memory leak.  With 1.2 fcs, there was a very LARGE memory leak (several hundred k per run).  With 1.2.2 build e this leak has been reduced to about 1k per run.  This however is still unacceptable.  Here is the data output from the -m option in SwingMark:

Used Memory     HeapSize
1986704 3260408
2602696 5439480
2612832 5472248
2614064 5476344
2614560 5476344
2615912 5476344
2616664 5476344
2619232 5480440
2619856 5480440
2619624 5480440

As you can see, the used memory in the JavaHeap increased from 2614k to 2619k between runs 4 and 10.  

I haven't get tracked down what is leaking, but I'm working on it.

Also, the SQE team's SwingBasher application (which is similar to SwingMark) is seeing probably related problems.  It can currently only run for about 24 hours without failing due to out of memory problems.  This is an improvement over 1.2 fcs, but it shoud run forever.

steve.wilson@eng Feb 3, 1999

Comments
EVALUATION OK, after closer evaluation it looks like SwingMark no longer leaks. I just takes a long time to get to a steady state. I ran it for 1000 runs and after about 50 it reached a steady state which each run finished within about 1k of the one before it. This bounced up and down but run 100 was within 1k or run 1000. So that at least means it isn't really leaking in the java heap, I suspect the memory manager just gets fragmented over the first 100 runs or so, and thus appears to have a small leak. I now have to try SwingBasher and see what I can find. steve.wilson@eng 1999-02-05 More info on this. The Java heap for SwingMark shows no evidence of a leak, but it seems there is a small leak in the C heap. The leak is less than 1k per run (perhaps as small as 300 bytes). This is likely related to bug ID# 4099615 - awt frames leak memory. It is possible that SwingBasher is seeing another leak (in addition to this), but we'll test it again once we get 4099615 fixed. steve.wilson@eng 1999-02-05 I little more info on this. I left SwingMark running on my machine for a couple days. It was on about run 4500 when I killed it. According to the NT process manager the working set had grown to 25.7 meg. This is a growth of about 4 meg from run 200 (by then a steady state had been reached in the java heap). This implies that the long-term leakage is about 1k per run, which is inline with 4099615.
11-06-2004