Is my Swing app allocating redundant objects?

Question

I've noticed that all Swing applications I've created seem to allocate new objects continuously.

Consider this small application:

import java.awt.Dimension;
import javax.swing.JFrame;
import javax.swing.JPanel;
@SuppressWarnings({ "javadoc", "serial" })
public class SwingTest extends JFrame {
    public static void main(String[] args) {
        new SwingTest().setVisible(true);
    }
    public SwingTest() {
        setTitle("SwingTest");
        setDefaultCloseOperation(EXIT_ON_CLOSE);
        JPanel panel = new JPanel();
        panel.setPreferredSize(new Dimension(400, 400));
        setContentPane(panel);
        pack();
    }
}

I wouldn't expect it to consume much memory, but if I look at the heap graph in VisualVM I see memory usage increasing constantly, then resetting. What causes this?

The tooth-saw pattern is probably caused by profiling itself. — Jakub Zaverka, Nov 15 '12 at 12:40
I would like to minimize GC work as much as possible, not specifically to remove delays in the GUI, but perhaps that is one good example of why extra GC activity is not desired. — user11171, Nov 15 '12 at 12:45
The sawtooth pattern should be caused by the GC sweeping dead references. — user11171, Nov 15 '12 at 12:46
No it is not - see http://stackoverflow.com/questions/7219532/why-a-sawtooth-shaped-graph — Jakub Zaverka, Nov 15 '12 at 12:53
Sorry, the correct link is http://stackoverflow.com/questions/13123457/jvm-sawtooth-idle-process — Jakub Zaverka, Nov 15 '12 at 12:59
confirmed to be introduced by the measuring itself: http://stackoverflow.com/questions/12958219/jvm-sawtooth-pattern-when-idle-what-does-the-jvm-do-in-the-meantime - the moral of the story: beware of your tools and avoid jumping to conclusions. _Swing is continuously allocating additional objects_ from looking at the heap only, is nothing but a wild assumption. Checking which objects are allocated by whom would have ... disproven that assumption ;-) — kleopatra, Nov 15 '12 at 13:11
@JakubZaverka I was referring to the dips in the allocated heap space, which obviously are caused by the garbage collector. I misunderstood your comment to be that those dips were caused by the profiler. I agree with you now that the extra memory usage seems to be caused by the profiler! Sorry for the confusion! — user11171, Nov 15 '12 at 14:37

score 2 · Accepted Answer · answered Nov 15 '12 at 13:44

Here is the result of profiling your code on my machine (OpenJDK 1.6.0_22 64 bits on linux 3.1.1, using Netbeans profiler)

flat profiling result

I suggest you to find out what those allocated objects are. You can do this by making memory snapshots and comparing them.

Note that the Netbeans profiler is the same codebase than VisualVM.

score 1 · Answer 2 · edited Oct 26 '17 at 12:16

1

Preventing Java allocating new objects, so the garbage collection is less costly, is against one of the main principles the Java was build in the first place. No, there is no way Swing can be prevented creating new objects - how would it function, without its crucial objects? There is no special, no-object mode of operation.

If the performance of garbage collection is so crucial that it is a concern for you, then Java is not the technology you should be using. If your application is time-critical, write it in C or any other low-level language, where you have control over such things as memory management performance.

edited Oct 26 '17 at 12:16

Archimedes Trajano

35,625
19
175
265

answered Nov 15 '12 at 12:51

Jakub Zaverka

8,816
3
32
48

One can easily avoid creating redundant objects by using an object pool. Managed memory is no excuse to waste memory. – user11171 Nov 15 '12 at 12:54
2

@user11171 So what's your problem exactly? You complain that Swing is creating too many objects? Or that garbage collection is too slow? Or both? – Jakub Zaverka Nov 15 '12 at 12:57

Is my Swing app allocating redundant objects?

2 Answers2