Why is there such a big difference in memory use of a Java application in Windows XP 32 vs Windows 7 64

I have a little Java application that I wrote for recording my work activities. Since I have it open all day, every day, one of the things that originally concerned me as to choice of language is the amount of memory it would use.

Happily, under Windows XP I it would typically consume about 5 MB when minimized and 12 or so when maximized, and happily runs with -Xmx5M (memory consumption according to Windows Task Manager).

When I upgraded my home PC with newer hardware, and at the same time, to Windows 7 64, (although I installed and am using the 32 bit JVM), I immediately noted that the JVM for this application now reports 68 MB+ always... and that's with -Xmx5M -Xss16K, according to Task Manager's "Working Set".

Both the old and new machines had/have 4 GB of RAM, of which 512 MB is used by video. Both were running recent builds of Java 6 - about update 15 for WinXP, and now update 24 for Win7. The application footprint on disk is 70 K in 12 classes. Moreover, my work computer is still Windows XP, running Java 6_24, and it shows about 12 MB for this identical application - and by identical I mean literally that, since the two systems are sync'd for all my development tools.

As a developer, I need to understand the reasons why my applications appear to chew up so much memory.

Can anyone shed some light on this, and suggest how to meaningfully reduce the memory footprint for a Java 6 application?

Edit

The answer may be in an excessive PermGen size. According to JVisualVM, I have a heap of:

Size: 5.2 MB, Used: 4.3 MB (peak) and Allocated 6.2 MB.

but for the PermGen

Size: 12.5 MB, Used: 4.6 MB (peak) and Allocated 67.1 MB.

So is it possible that the 68 MB shown in Task Manager in Win 7 is simply requested but unassigned virtual memory?

EDIT 2

Reducing PermGen to 12 MB had no effect on the process RAM, but JVisualVM did show it reduced (apparently 12 MB constitutes some s开发者_如何学Cort of minimum, because going lower than that had no effect in JVVM).

The 64 bit OS uses 64 bits as the size of pointers while a 32 bit OS uses 32 bits. That might just be one of the reasons though.

Remember that everything in Java is a pointer (for the most part) so when switching to a 64 bit machine, with 64 bit memory addresses, your pointers double in size.

There is an option in the JVM (-XX:+UseCompressedOops) to turn on compressed object pointers. This will put your memory usage near the levels you saw on 32 bit machines.

For the 64-bit JVM you can specify an option that will reduce the overhead of 64-bit addressing. As long as the heap is under 32GB it can essentially compress the pointers back to 32-bit. In a typical Java application this saves about 40% of the memory. See Compressed oops in the Hotspot JVM for more details. Here's the option for it:

-XX:+UseCompressedOops

Note that if you use a 32-bit JVM on a 64-bit OS that you won't pay the overhead of 64-bit memory addresses (although there's a different overhead to pay there in translation, yet it's very minor).

I believe that Windows 7 doesn't report memory use the same as XP either (I don't have a reference offhand though). So for a fair comparison of 32-bit vs 64-bit you need to run both on the same version of Windows.

This has nothing to do with the operating system being 64-bit - Windows XP and Windows 7 use RAM in very different ways.

Because of this, Windows 7 will almost always report all programs as using more memory than Windows XP did. Don't worry about this - this is just a result of Windows 7 using your memory the way it should be: as a cache.

While it's not the whole story, the PermGen size is 30% larger on 64-bit plaforms:

-XX:MaxPermSize - Size of the Permanent Generation. [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]

• Java 6 HotSpot VM Options