This section provides a tutorial example on how to save footprint by restoring shared archive 'java -Xshare:on'.
To see the saving on footprint with restoring shared archive, I am planning
to run LongSleep with and without the CDS feature. Here is my test results:
\j2sdk1.5.0\bin\java -cp . -Xshare:off LongSleep
Free memory: 1879160
Total memory: 2031616
(Windows Task Manager shows: Mem Usage = 5340K)
\j2sdk1.5.0\bin\java -cp . -Xshare:on LongSleep
Free memory: 1879152
Total memory: 2031616
(Windows Task Manager shows: Mem Usage = 6032K)
What a surprise! The CDS feature actually increased the footprint of LongSleep.
Can anyone help to explain why?
Steve Bohne from the CDS implementation team at Sun.COM emailed in 2007 the following answer.
It is due to the memory accounting on Windows.
Basically, Windows
charges each process for the same shared data. My
blog entry explains
this further, and gives a more accurate measurement
technique:
http://blogs.sun.com/sbohne/entry/share_and_enjoy_memory_usage
Steve's blog says that Windows Task Manager report the total memory used by each process, including
both the private portion and the shared portion. The CDS feature will increase the shared portion
of each JVM process, which could not be reported by Window Task Manager.
Other tools should be used to see the details of a JVM process memory usage.
