1

Hello i am programming twin panel file manager in java and i am facing a problem.

Whenever I scroll JTable it takes about 8M more memory... Is there a way how to fix that ? It stops everytime after consuming 40 - 60M of memory. Is it a Swing component problem ?

Thank you for your responses.

Edit

I tried to understand why it takes so much memory. Now i know the source of the problem. I made a small button with this actionPerformed: jScrollPane1.repaint();.

When I hit it 10 times i got big memory consumptions in task manager and also in VisualVM. But in VisualVM GC starts to collect on 50 MB and lowers it to 8 Mb. But windows taskmanager is still increasing its value.

The repaint method is making big memory leaks in windows. Is there any fix ?

Edit2

A further research of this problem gave me this. I tried to run this program on Linux platform with no leaking. The program had about 20 M of memory used. So i've programmed a little thread which was invoking the method repaint on both JScrollPanes. And to my suprise on Windows machine memory was rising until 110 M but then the OS started to push harder on memory.

The Thread:

@Override
public void run() {
        while (true) {
            jScrollPane1.repaint();
            jScrollPane2.repaint();
            try {
                this.sleep(10);
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }
        }
    }

I was doing normal copy/rename/delete operations also was going through directories with no memory rising. I noticed that the memory was also decreasing to 99M.

On the monitoring thread:

@Override
public void run() {
    while (true) {
        aLabel.setText("Memory consumption: " + (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory());
        try {
            this.sleep(200);
        } catch (InterruptedException ex) {
            ex.printStackTrace();
        }
    }
}

the numbers were from 8M to 50M and then again 8M. So garbage collecting was successful. So the real problem is windows platform or the compatibilty of the JVM ? As trashgod suggested that task manager is not precise in getting the memory consumptions but the memory is being really used by the java process.

Animator
  • 179
  • 12
  • Is it possible that you open the files / directories and not closing them? – MByD Jan 02 '12 at 15:41
  • 1
    please why your JTable take ..., can you explains, post a http://sscce.org/, everything another are shots to the dark – mKorbel Jan 02 '12 at 15:42
  • 1
    8K is nothing. It could come from the graphics that must be updated, from the temporary objects created by the renderer, you just shouldn't care. – JB Nizet Jan 02 '12 at 15:42
  • 1
    60-80K? Still don't care. Did you profile this to know where the memory is being consumed, or are you just assuming it's JTable? – duffymo Jan 02 '12 at 15:56
  • Well as i said. Clean JFrame with only JTable. When i run the program i have about 35K used memory. Whenever I scroll IN the JTable i am getting big memory consumptions. – Animator Jan 02 '12 at 16:03
  • 1
    The garbage collector will probably reclaim this memory when it feels it should, which might mean some time later, or never, because there is plenty of memory available and there is no need to GC. – JB Nizet Jan 02 '12 at 16:05
  • And there is just no way how to stop this memory leaking ? – Animator Jan 02 '12 at 16:12
  • It's probably not leaking. If you start a JVM with a max heap size of 64M and the consumed memory is 20M and goes up to 20.1M, the GC doesn't care. It probably cares even less if the consumed memory is less that the initial heap size. Now if the memory climbs up to 63M, then it'll reclaim memory more agressively. I think you're pre-optimizing. – JB Nizet Jan 02 '12 at 16:30

2 Answers2

1

Invoking FileSystemView.getFileSystemView() repeatedly may be a problem, as suggested here and profiled here. It may help to edit your question to include an sscce that demonstrates the problem. Using a profiler may suggest the scope and severity of the problem; Java VisualVM may already be installed.

Windows task manager is still increasing its value.

The Windows task manager may not be entirely dispositive, as suggested here. In this context, the jvisualvm result may be more reliable.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • I figured it out I think. I spent 3 hours of testing and came to this conclusion... I run my program on Windows Platform and run VisualVM. Also i made a small thread which was monitoring Runtime freememory. I always get maximum used memory in heap 11 Mb. But Windows task manager is giving me numbers like 70 - 180 Mb. So... I run it on Linux machine and task manager gave me 20 Mb and 30 max. So i think microsoft has some bad task enumerating or something. – Animator Jan 02 '12 at 19:09
  • As @JB Nizet observed above, the there may be no problem. I suspect that the Windows task manager result may be misleading, as suggested in these [comments](http://stackoverflow.com/a/8463014/230513). See also this related [answer](http://stackoverflow.com/a/8462992/230513). – trashgod Jan 02 '12 at 19:26
  • I tried to understand why it takes so much memory. Now i know the source of the problem. I made a small button with this actionPerformed: `jScrollPane1.repaint();`. When I hit it 10 times i got big memory consumptions in task manager and also in VisualVM. But in VisualVM GC starts to collect on 50 MB and lowers it to 8 Mb. But windows taskmanager is still increasing its value. I think there should be some fix for the repainting of the jScrollPane when scrolling... – Animator Jan 02 '12 at 19:48
  • Yes but, that memory which is in the task manager is really being used! I've tested it and got OutOfMemoryException. – Animator Jan 03 '12 at 08:03
0

never use Thread#sleep during EDT, that reason why you get un_expecting UsedMemory,

1) Swing GUI is single threaded

2) Swing GUI waits for all events done, all changes are done on screen in one moment, including usage of Thread#sleep,

3) by using Thread#sleep you can simulating and see on the screen un_expected repaint of GUI, or value aren't refreshed or repainted

4) you have issues with Concurency in Swing

5) I can't see any reason for using repaint() there, notice that very hard method for local enviroment

6) use and wrap you code to the

7) since I have a few methods when is required (deliberate) usage Thread#sleep, not easy job without Controler covered whole EDT

mKorbel
  • 109,525
  • 20
  • 134
  • 319
  • These two threads are invoked because of testing. The repaint method was causing heavy memory loads so I made a thread which was invoking the repaint method automatically. – Animator Jan 03 '12 at 09:58
  • Also the threads are not the source of unexpected usedMemory - the repaint method is the source. I don't know what do you mean with this answer to my problem at all. – Animator Jan 03 '12 at 10:04
  • redirect that to the SwingWorker or Runnable#Thread, by delaing SwingxTimer or util#Timer, then you can testing whatever in SWing GUI correctly, otherwise your test shouldn't be accurated, there nothing about Java Esential Classes, there going about GUI, and lots of these methods came from Native OS – mKorbel Jan 03 '12 at 10:04
  • in other hands you throws all enviroment resouces by using Thread#sleep, GUI only freeze durring waiting for Thread#sleep ends, nothins else, – mKorbel Jan 03 '12 at 10:07
  • Ok, i've made a swing worker but can you tell me how to delay it ? I cant use Thread.currentThread.sleep() ? Thanks in advance. – Animator Jan 03 '12 at 10:20
  • inside SwingWorker or Runnable#Thread you can play with Thread#sleep, there are bridges to the Java Essential Classes – mKorbel Jan 03 '12 at 11:28
  • 1
    @islander: What problem are you trying to solve by repainting scroll panes at such high frequency? Please provide an [sscce](http://sscce.org/) that exhibits the problem you describe. – trashgod Jan 03 '12 at 12:04
  • 1
    @trashgod that right (:- but most peoples that comings here working on top secrets project for their Authority, then why did you suprised :-) – mKorbel Jan 03 '12 at 12:17
  • Did you ever read everything what was behind this ? I explained everything i want to get solved. Third time I am going to say that, the repaint is called at this frequency because I wanted to research the memory leaks of JScrollPane because when I scroll the jtable automatically JViewPort is changed and repaint method is called. Why should I post code ? I also said at the beginning it is problem with just simple jframe and 1 JScrollPane after scrolling (big memory usage). The problem was and is why it is giving away so much memory in windows! – Animator Jan 03 '12 at 13:34
  • your thread touched great Java and Swing Gurus as (trashgod, JB Nizet, duffymo) with some asks, why we must to ask you for your help, your clarify, ....whatever, just for answering to your question, – mKorbel Jan 03 '12 at 13:48
  • I don't understand your english, sorry. I was just looking for help and my question is formulated very clearly. I think only you were unhelpful mKorbel and also making fun from people that they are not sharing their code in a case that it is absolutely not required ? Thanks. – Animator Jan 03 '12 at 17:17