Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30376 > unrolled thread

heap memory issue, related with garbage collection

Back to article view | Back to comp.lang.java.programmer

Contents

  heap memory issue, related with garbage collection John <xsli2@yahoo.com> - 2014-11-21 08:41 -0800
    Re: heap memory issue, related with garbage collection Tassilo Horn <tsdh@gnu.org> - 2014-11-21 17:47 +0100
    Re: heap memory issue, related with garbage collection Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-21 11:49 -0500
      Re: heap memory issue, related with garbage collection John <xsli2@yahoo.com> - 2014-11-21 10:49 -0800
        Re: heap memory issue, related with garbage collection Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-21 14:32 -0500
          Re: heap memory issue, related with garbage collection John <xsli2@yahoo.com> - 2014-11-28 13:29 -0800
            Re: heap memory issue, related with garbage collection Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-28 17:20 -0500

#30376 — heap memory issue, related with garbage collection

Hi:

My standalone Java program displays a series of PNG files in a JFrame. Those PNG files were screen shots captured earlier with several seconds interval. There are hundreds of those PNG files.

The code is like:

    //the method below is repeated called with some interval: displayPic(++count);
    //so the PNG files are displayed one by one without stop -- like viewing a movie. The only problem is that after displaying about 100 PNG files, out of heap memory error occurs. If I increase heap memory: java -jar -Xmx2024m myJar.jar /pngFolder/
   //I can play more PNG files, but the error still happen eventually. I hope I can do some garbage collection to really solve the problem. Thank you.
    

    private void displayPic(final int picCount)
    {

        String pngFileNameWithPath = xxx; //get PNG file name based on int picCount
 
        final ImageIcon imageIcon = new ImageIcon(pngFileNameWithPath);

        final JLabel picLabel = new JLabel();
        picLabel.setIcon(imageIcon);

        final JPanel picPanel = new JPanel();
        picPanel.add(picLabel);

        _jPanel.add(picPanel, BorderLayout.CENTER);

        _jFrame.getContentPane().add(_jPanel);

        _jFrame.setTitle(pngFileNameWithPath);

        _jFrame.setVisible(true);
    }

[toc] | [next] | [standalone]

#30377

John <xsli2@yahoo.com> writes:

Hi John,

>     //the method below is repeated called with some interval: displayPic(++count);
>     //so the PNG files are displayed one by one without stop -- like viewing a movie. The only problem is that after displaying about 100 PNG files, out of heap memory error occurs. If I increase heap memory: java -jar -Xmx2024m myJar.jar /pngFolder/
>    //I can play more PNG files, but the error still happen eventually. I hope I can do some garbage collection to really solve the problem. Thank you.
>     
>
>     private void displayPic(final int picCount)
>     {
>
>         String pngFileNameWithPath = xxx; //get PNG file name based on int picCount
>  
>         final ImageIcon imageIcon = new ImageIcon(pngFileNameWithPath);
>
>         final JLabel picLabel = new JLabel();
>         picLabel.setIcon(imageIcon);

You create hundreds of JLabels, each with another ImageIcon and add all
of them to the content pane of your frame.  So all images have to be
kept in memory.  Why doesn't your class have a picLabel field, and this
method just sets its icon to another PNG?

Bye,
Tassilo

[toc] | [prev] | [next] | [standalone]

#30378

On 11/21/2014 11:41 AM, John wrote:
> Hi:
>
> My standalone Java program displays a series of PNG files in a JFrame. Those PNG files were screen shots captured earlier with several seconds interval. There are hundreds of those PNG files.
>
> The code is like:
>
>      //the method below is repeated called with some interval: displayPic(++count);
>      //so the PNG files are displayed one by one without stop -- like viewing a movie. The only problem is that after displaying about 100 PNG files, out of heap memory error occurs. If I increase heap memory: java -jar -Xmx2024m myJar.jar /pngFolder/
>     //I can play more PNG files, but the error still happen eventually. I hope I can do some garbage collection to really solve the problem. Thank you.
>
>
>      private void displayPic(final int picCount)
>      {
>
>          String pngFileNameWithPath = xxx; //get PNG file name based on int picCount
>
>          final ImageIcon imageIcon = new ImageIcon(pngFileNameWithPath);
>
>          final JLabel picLabel = new JLabel();
>          picLabel.setIcon(imageIcon);
>
>          final JPanel picPanel = new JPanel();
>          picPanel.add(picLabel);
>
>          _jPanel.add(picPanel, BorderLayout.CENTER);
>
>          _jFrame.getContentPane().add(_jPanel);
>
>          _jFrame.setTitle(pngFileNameWithPath);
>
>          _jFrame.setVisible(true);
>      }

     You keep adding image after image to the same (?) JPanel and
then to the same (?) JFrame; do you ever remove any of them, or
do you just let them pile atop each other to a dizzying height?

     (I'm not 100% sure of this diagnosis, because you've not shown
what _jPanel and _jFrame are, nor how they are managed.  One thing
looks odd, though it probably has nothing to do with your memory
issue: Shouldn't you call _jFrame.pack() after changing its content?)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#30379

Thank you for all your replies. 

My original post missed some information which now is critical. My program has two buttons besides other buttons: one button is "Next" and one button is "ContinueouslyPlay". When clicking button "ContinueouslyPlay", a child thread is repeatedly calling displayPic() with incremented parameter. The code above works well since all the variables are local - so the thread 'see' the new objects without problem. The problem is out of heap memory when reaching picture 150.(If clicking "Next" button, it is the main thread displaying next picture only - very simple.)

Now, I have changed those variables to class instance variables. Now concurrent programming adds the complexity: in "ContinueouslyPlay" mode, very often the displayed one remain unchanged for quite a bit even though the title is showing the next, next etc picture file names. So the child thread does not 'see' the new stuff. I have added 'volatile' keyword to the instance variables. No help. There is no out of heap memory error any more. But such no displaying is more annoying. Here is the code(I think using a separate thread for "ContinueouslyPlay" mode is reasonable and I don't want to change it. Otherwise all other buttons are not responsive):

public class PictureDisplayer implements ActionListener {
    private final JFrame _jFrame;
    private final JPanel _jPanel;
    private volatile JLabel _picLabel;
    private volatile JPanel _picPanel;
    private volatile ImageIcon _imageIcon;
    ..
   public PictureDisplayer() throws Exception
    {
        _jFrame = new JFrame();
        _jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        _jFrame.setSize(Constants.MONITOR_WIDTH, Constants.MONITOR_HEIGHT);
        _jPanel = new JPanel(new BorderLayout());
        //Create the toolbar.
        final JToolBar toolBar = new JToolBar("Still draggable");

        //Lay out the main panel.
        _jPanel.setPreferredSize(new Dimension(Constants.MONITOR_WIDTH, Constants.MONITOR_HEIGHT));
        _jPanel.add(toolBar, BorderLayout.PAGE_START);
        _picLabel = new JLabel();
        _picPanel = new JPanel();

        _runThread = new Thread(new Runnable() {
            public void run() {
                while(true) {
                    displayPic(++_picCount);
                    try {
                        Thread.sleep(10000);
                    }
                    catch(final Exception e) {//hopefully never happen
                    }
                }
            }
        });
        ..
    }

    private void displayPic(final int picCount)
    {
        String pngFileNameWithPath = xxx; //create PNG file name from picCount

         _imageIcon = new ImageIcon(pngFileNameWithPath);
        _picLabel.setIcon(_imageIcon);
        _picPanel.add(_picLabel);
        _jPanel.add(_picPanel, BorderLayout.CENTER);
        _jFrame.getContentPane().add(_jPanel);
        _jFrame.setTitle(pngFileNameWithPath);
        _jFrame.setVisible(true);
    }

   public void actionPerformed(final ActionEvent evt) {
    ..
   }
}

Thank you very much.

[toc] | [prev] | [next] | [standalone]

#30380

On 11/21/2014 1:49 PM, John wrote:
> Thank you for all your replies.
>
> My original post missed some information which now is critical. My program has two buttons besides other buttons: one button is "Next" and one button is "ContinueouslyPlay". When clicking button "ContinueouslyPlay", a child thread is repeatedly calling displayPic() with incremented parameter. The code above works well since all the variables are local - so the thread 'see' the new objects without problem. The problem is out of heap memory when reaching picture 150.(If clicking "Next" button, it is the main thread displaying next picture only - very simple.)
>
> Now, I have changed those variables to class instance variables. Now concurrent programming adds the complexity: in "ContinueouslyPlay" mode, very often the displayed one remain unchanged for quite a bit even though the title is showing the next, next etc picture file names. So the child thread does not 'see' the new stuff. I have added 'volatile' keyword to the instance variables. No help. There is no out of heap memory error any more. But such no displaying is more annoying. Here is the code(I think using a separate thread for "ContinueouslyPlay" mode is reasonable and I don't want to change it. Otherwise all other buttons are not responsive):
>
> public class PictureDisplayer implements ActionListener {
>      private final JFrame _jFrame;
>      private final JPanel _jPanel;
>      private volatile JLabel _picLabel;
>      private volatile JPanel _picPanel;

     There is no need for these to be `volatile', because nothing
ever changes them after the constructor finishes.  Far from being
`volatile', they could perfectly well be `final'.

>      private volatile ImageIcon _imageIcon;

     This one can't be `final', but there's also no need for it to
be `volatile'.  In fact, there's no need for it to be an instance
variable; it would be better as a local inside displayPic().

>      ..
>     public PictureDisplayer() throws Exception
>      {
>          _jFrame = new JFrame();
>          _jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>          _jFrame.setSize(Constants.MONITOR_WIDTH, Constants.MONITOR_HEIGHT);
>          _jPanel = new JPanel(new BorderLayout());
>          //Create the toolbar.
>          final JToolBar toolBar = new JToolBar("Still draggable");
>
>          //Lay out the main panel.
>          _jPanel.setPreferredSize(new Dimension(Constants.MONITOR_WIDTH, Constants.MONITOR_HEIGHT));
>          _jPanel.add(toolBar, BorderLayout.PAGE_START);
>          _picLabel = new JLabel();
>          _picPanel = new JPanel();
>
>          _runThread = new Thread(new Runnable() {
>              public void run() {
>                  while(true) {
>                      displayPic(++_picCount);
>                      try {
>                          Thread.sleep(10000);
>                      }
>                      catch(final Exception e) {//hopefully never happen
>                      }
>                  }
>              }
>          });

     If this thread ever executes, your program is thread-broken. As
the Javadoc for javax.swing says,

	"All Swing components and related classes, unless otherwise
	documented, must be accessed on the event dispatching thread."

     Question 1: Is _runThread the event dispatching thread?
     Answer 1: No, it is a completely different thread.

     Question 2: Does _runThread access Swing components?
     Answer 2: Yes, it accesses a JLabel, two JPanels, and a JFrame.

     Question 3: Is your program thread-safe?
     Answer 3: Not if _runThread runs.

     It seems to me that your understanding of thread programming and
of thread-safety issues is not yet well-developed.  Your claim that
"all the variables are local - so the thread 'see' the new objects
without problem" is nonsense, and serves as evidence that you don't
know what you're doing.  Try studying (or re-studying)

https://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html

     Based on what you've shown, I don't know why your program runs
out of memory.  Yes, you keep adding the same JLabel to the same
JPanel, adding that JPanel to yet another JPanel, and adding that
second JPanel to the JFrame, over and over and over again.  But
after the first time all this adding and re-adding should just be
complicated no-ops; it shouldn't cause memory exhaustion.

     However, the fact that you're doing all this stuff on a thread
that is not the EDT means that all bets are off: You cannot count
on Swing to behave as advertised if you use it improperly, as you're
doing.  Fix the threading problems, and come back afterwards if you
still have trouble.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#30438

I solved my problem.
Here is my original code:

    private void displayPic(final int picCount) 
    { 

        String pngFileNameWithPath = xxx; //get PNG file name based on int picCount 
  
        final ImageIcon imageIcon = new ImageIcon(pngFileNameWithPath); 

        final JLabel picLabel = new JLabel(); 
        picLabel.setIcon(imageIcon); 

        final JPanel picPanel = new JPanel(); 
        picPanel.add(picLabel); 

        _jPanel.add(picPanel, BorderLayout.CENTER); 

        _jFrame.getContentPane().add(_jPanel); 

        _jFrame.setTitle(pngFileNameWithPath); 

        _jFrame.setVisible(true); 
    } 

The problem is when this method was called 150 times, then heap memory ran out. I found the cause is that at the end of the method, even though those references('picLabel', 'picLabel' etc) are out of scope and dead, the objects that once were referenced by them were not garbage collected and that was due to that those objects, even though not referenced by 'picLabel', 'picLabel' etc, were still referenced by some other references. In order to make those objects really collected by JVM garbage collection, I added these code near the end of the method:
            picLabel.removeAll();
            picPanel.removeAll();
            _jPanel.remove(picPanel);
            _jFrame.getContentPane().remove(_jPanel);

I am not sure if they all are needed or if one is covering another. But anyway, I can keep all references inside the method(no need to make them class instance variables) and no more memory issue.

[toc] | [prev] | [next] | [standalone]

#30439

On 11/28/2014 4:29 PM, John wrote:
> I solved my problem.

     Congratulations!  But read on ...

> Here is my original code:
>
>      private void displayPic(final int picCount)
>      {
>
>          String pngFileNameWithPath = xxx; //get PNG file name based on int picCount
>
>          final ImageIcon imageIcon = new ImageIcon(pngFileNameWithPath);
>
>          final JLabel picLabel = new JLabel();
>          picLabel.setIcon(imageIcon);
>
>          final JPanel picPanel = new JPanel();
>          picPanel.add(picLabel);
>
>          _jPanel.add(picPanel, BorderLayout.CENTER);
>
>          _jFrame.getContentPane().add(_jPanel);
>
>          _jFrame.setTitle(pngFileNameWithPath);
>
>          _jFrame.setVisible(true);
>      }
> The problem is when this method was called 150 times, then heap memory ran out. I found the cause is that at the end of the method, even though those references('picLabel', 'picLabel' etc) are out of scope and dead, the objects that once were referenced by them were not garbage collected and that was due to that those objects, even though not referenced by 'picLabel', 'picLabel' etc, were still referenced by some other references.

     Yes: As Tassilo Horn and I wrote, you added these objects to the
frame (over and over again).  The frame, naturally, needs to keep
references to the things it contains, and those references just kept
piling up, "pinning" the objects they referred to.

> I added these code near the end of the method:
>              picLabel.removeAll();
>              picPanel.removeAll();
>              _jPanel.remove(picPanel);
>              _jFrame.getContentPane().remove(_jPanel);

     Removing things before adding new ones is a good idea, but what
do you mean by "near the end?"  Removing what you've just added is
not only pointless, but counterproductive.  You *should* wind up with
nothing showing at all (unless you're still doing things from the
wrong thread, in which case there's no telling what might happen).

> I am not sure if they all are needed or if one is covering another. But anyway, I can keep all references inside the method(no need to make them class instance variables) and no more memory issue.

     Read Tassilo Horn's response again.  All this adding and removing
is *much* more work than is needed; you've built a sort of Rube Goldberg
program, a mechanism far more complex than the job requires.  All you
really need to do is

     - When you construct the GUI, put a JLabel in a JPanel and put the
JPanel in the JFrame.  You never need to remove anything, and you never
need to add anything else except whatever buttons and things you might
require.

     - When you want to display a new image, build the ImageIcon just as
you do now, and just call setIcon() on the JLabel.

     - Remember to do all these things on the Event Dispatch Thread.

... and that's it!  No adding, removing, or pointless running around.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web