0

I know that the JVM is a hoarder but this is was a shock to me: 180MB usage on startup with netbean's very basic "Contact Editor" GUI with an addition of some basic generic instances?

I didn't build a 1998 circa first person shooter game. I beg SO community to enlighten me on this one. Here is a JConsole print screen:

enter image description here

Also: i have 18 threads on startup that never die. Are there any other threads besides the initial thread and Swing's dispatch thread that always exist?

mKorbel
  • 109,525
  • 20
  • 134
  • 319
Tom
  • 9,275
  • 25
  • 89
  • 147

2 Answers2

1

I'm not familiar with Contact Editor, but an embedded database or emulator might be responsible. My favorite JVM runs 10 threads for a typical Swing GUI, but only three are active and none really do much. This example profiles a visually "busy" program, and this example uses an artificially small heap to highlight the range.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
1

Threads are not really a memory problem (about half of those 18 are just because you are in debug mode IIRC). The other ones have pretty obvious names (my guesses): AWT-Shutdown (to check if all windows dispose, then exit JVM), AWT-Windows (get events from the OS), Java2D disposer (image data clean up).

I don't know the program you're running but if it is based on the Netbeans platform that probably adds some extra memory requirement, but not 180MB. I guess most of the memory is either not used (just reserved) or is actual data taking up memory.

For comparison:

  • a simple JFrame with a label and a button only needs ~2MB (runs with -Xmx2MB, although visualvm show it has 8MB reserved (minimum on 64bit Windows?), <2MB used).
  • a complex GUI program I develop with 70MB of libraries (jars) is after starting ~35MB (where my guess is ~5-10MB just icons/images) and after using all functionality (so almost all library code loaded, including non GUI ones) ~100MB but that includes some data.

Breakdown:

  1. java.awt.image.BufferedImage#156 7.056.378
  2. java.awt.image.BufferedImage#415 6.639.738
  3. sun.misc.Launcher$AppClassLoader#1 3.386.545
  4. class com.ces.core.gui.help.WelcomeTab 627.256 (static image data here)
  5. class com.ces.util.resources.Translator 408.146 (basically all text displayed in the UI)
  6. sun.awt.AppContext#1 389.760
  7. java.awt.image.BufferedImage#161 326.120

About half looks like cached images (big background images :)) I left out the int[]/Object[]/HashMap.Entry[] which refers to the same data)

If you want to see the breakdown for you example app -> VisualVM -> Monitor -> Heap dump -> Find x biggest objects by retained size.

Walter Laan
  • 2,956
  • 17
  • 15