Re: Memory Leak

• Subject: Re: Memory Leak
• From: Bill Stackhouse <email@hidden>
• Date: Tue, 09 Nov 2010 13:30:23 -0800
• Delivered-to: email@hidden
• Delivered-to: email@hidden
• User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6

I would guess you might just need to call System.gc() periodically to
get garbage collection to run.

On 11/9/10 12:24 PM, Josh Marinacci wrote:
> I'm not sure this test will show you want you want.  Every time you call label.setText() it is going to fire a property change event. However, since you are doing this in a continuous loop without exiting your method, the rest of the EDT never gets a chance to process those events.  This likely means you are just dumping 100000000 event objects into a queue that never gets cleaned up.  Does this accurately reflect your realworld scenario?  What if you create a thread which invokes label.setText() on the EDT?  ex:
>
> new Thread(new Runnable() {
> public void run() {
> for(long i=0; i<100000000;i++) {
> 	long t = i;
> 	SwingUtiltiies.invokeLater(new Runnable(){ public void run() {
> 		label.setText(String.valueOf(t));
> 	});
> }
> }
> }
> ).start();
>
> This should let the EDT actually process your update events.
>
> - Josh
>
> On Nov 8, 2010, at 4:36 PM, Russ Calvert wrote:
>
>> I've got a strange memory leak that I'm trying to understand and find a way to fix or get around.  The problem was first reported by a customer who found that after running for a very long time, my software becomes very slow and unresponsive.  This turned out to be due to a slow increase in the amount of memory being used, as shown in Activity Monitor.  After much investigation, I've found a simple test case that illustrates the problem.  This consists of a JLabel displayed in a JFrame, with the text of the JLabel being very frequently updated:
>>
>>
>> import java.awt.*;
>> import javax.swing.*;
>>
>> public class Memory_Leak extends JFrame {
>>
>> 	public Memory_Leak() {
>> 		super("Memory_Leak");
>>
>> 		JLabel label = new JLabel();
>> 		label.setPreferredSize(new Dimension(200, 100));
>> 		getContentPane().add(label, BorderLayout.CENTER);
>> 		pack();
>> 		setVisible(true);
>>
>> 		for (long i=0; i<100000000; i++) {
>> 			label.setText(String.valueOf(i));
>> 		}
>> 	}
>>
>> 	public static void main(String args[]) {
>> 		new Memory_Leak();
>> 	}
>> }
>>
>>
>> When this little program is run (which typically takes several minutes), the real memory consumption as displayed in Activity Monitor slowly grows and grows and grows, by about 3MB in the test I've just run.  Monitoring with JConsole shows that both heap and non-heap memory remain roughly constant, but the total number of classes loaded grows linearly with time from about 1,700 to 14,000 during execution.  This class loading looks odd to me, but maybe it's normal - I don't understand what goes on in the depths of a JVM.  I've not bothered trying to analyse heap dumps, as the constant heap size suggests that I would be wasting my time.  One other thing I've noticed is that the leak seems to be many times faster with OSX 10.4 than OSX 10.5/6.
>>
>> Does anyone understand what's going on here, and/or how I remove the memory leak?
>>
>> Thanks in advance.
>>
>> Russ Calvert
>> AstroGrav Astronomy Software
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Java-dev mailing list      (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> Blasting forth in three part harmony!
>
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Java-dev mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

• Prev by Date: Re: Memory Leak
• Next by Date: Re: Memory Leak
• Previous by thread: Re: Memory Leak
• Next by thread: Re: Memory Leak
• Index(es):
  • Date
  • Thread