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.
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...:
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
