A ton of primitive types created at runtime

[Mike]

Hi gurus,

I ran some tests with VisualVM against my server app and for some reason it creates a whole lot of int[] (even though I never create a int[] in my code). Every time a user logs in VisualVM says that about 10MB of int[]s gets created. When running a heap dump they all disappear (due to the gc linked to the heap dump) and they never stay in memory.

If I run eclipse debug with a breakpoint on the first line at the same time as VisualVM the first line on the server ‘System.out.println(“Starting Server”);’ generates about 10MB of int arrays.

Did anyone run into something similar before? I also ran some checks and when I don’t run the server in debug mode or at the same time as VisualVM it uses a lot less memory (the int[]'s?). What method should I use to get a believable good view of my memory usage? Printing out the runtime.freeMemory sounds like the most reliable way but then I have no insight into what objects are taking up the heap.

Kind regards,
Mike

[CommanderKeith]

Hi,

It’s probably java2D creating all of the int arrays since they back images.

Using netbeans profiler you can take a snapshot of the heap (a heap dump) and you can see what methods allocate what objects. Maybe give netbeans profiler a spin?

Keith

[ra4king]

You can take a snapshot of the heap in VisualVM too. And this can’t be Java2D because, as he states, this is a server app. Do you have some code to show us where you see the int arrays being created?

[lhkbob]

If you didn’t create the int[]'s then something else is, such as the PrintStream attached to standard out. This is plausible since it likely buffers its output (although 10M seems excessive). However, it probably isn’t a memory leak since the heap dump gets rid of them. Java won’t GC unless needed and 10M won’t really push the memory limits.

Profiling always changes the way your code runs so you must analyze the results carefully, but I wouldn’t worry about it. It is extremely unlikely that you’ve found memory bugs in the JVM. One thing to check for, however, is that you’re using the server code correctly and not holding onto streams longer than you need to or are forgetting to close them.

I like using Runtime.freeMemory() and System.nanoTime() and the related methods to do course profiling within my code. That way all the JIT optimizations can kick in and I don’t have to worry about the profiler messing with things behind my back. As you’ve noticed, the information is not as useful or informative, though.

[Mike]

@CommanderKeith

Hi,

It’s probably java2D creating all of the int arrays since they back images.

Using netbeans profiler you can take a snapshot of the heap (a heap dump) and you can see what methods allocate what objects. Maybe give netbeans profiler a spin?

Keith

It’s an server app and as I stated the heap dump never displays anything seeing as the primitive types never stay in memory.

@ra4king

You can take a snapshot of the heap in VisualVM too. And this can’t be Java2D because, as he states, this is a server app. Do you have some code to show us where you see the int arrays being created?

System.out.println(“Starting Server”); for example, which made no sense until I read…:

@lhkbob

If you didn’t create the int[]'s then something else is, such as the PrintStream attached to standard out. This is plausible since it likely buffers its output (although 10M seems excessive). However, it probably isn’t a memory leak since the heap dump gets rid of them. Java won’t GC unless needed and 10M won’t really push the memory limits.

Profiling always changes the way your code runs so you must analyze the results carefully, but I wouldn’t worry about it. It is extremely unlikely that you’ve found memory bugs in the JVM. One thing to check for, however, is that you’re using the server code correctly and not holding onto streams longer than you need to or are forgetting to close them.

I like using Runtime.freeMemory() and System.nanoTime() and the related methods to do course profiling within my code. That way all the JIT optimizations can kick in and I don’t have to worry about the profiler messing with things behind my back. As you’ve noticed, the information is not as useful or informative, though.

Thanks a ton, I expected that to be the case but it’s good to get it confirmed