Class Data Sharing

Part:   1  2  3 

(Continued from previous part...)

Test 3 - Footprint Saving with Restoring Shared Archive

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

Viewing Shared Memory of JVM Processes

As suggested by Steve Bohne from Sun.COM, if you want to see the shared memory usage of JVM processes, you should install vadump.exe from Microsoft.

vadump.exe is a command line tool that shows very detailed information of a running process on a Windows system. There are 3 options you need to use with vadump.exe to get the private memory and shared memory usages:

• "-p PID" - Specifies a running process by the process ID, which can be obtained by the tasklist.exe command on a Windows XP system.
• "-o" - Tells vadump.exe to report a snapshot of the workingset of the specified process.
• "-s" - Tells vadump.exe to print summary information only.

With vadump.exe and tasklist.exe ready, let's see how how much memory will be shared by multiple JVM processes with CDS turned off:

(Open first command window)
C:\>\progra~1\java\jdk1.6.0_02\bin\java -cp . -Xshare:off
   LongSleep
 Free memory: 4997088
Total memory: 5177344

(Open second command window)
C:\>\progra~1\java\jdk1.6.0_02\bin\java -cp . -Xshare:off
   LongSleep
 Free memory: 4997088
Total memory: 5177344

(Open third command window)
C:\>tasklist
Image Name       PID Session Name Session# Mem Usage
============= ====== ============ ======== =========
...
java.exe        2312                     0   6,580 K
java.exe        3920                     0   6,548 K
(tasklist.exe reports the total memory usage 
   in the same way as Windows Task Manager)

C:\>\progra~1\resour~1\vadump -o -s -p 2312
Catagory                     Total    Private Shareable Shared
                         Pages KBytes  KBytes    KBytes KBytes
...
      Total Modules        794   3176     300         0   2876
      Total Dynamic Data   816   3264    3120         4    140
      Total System          45    180     180         0      0
Grand Total Working Set   1655   6620    3600         4   3016

C:\>\progra~1\resour~1\vadump -o -s -p 3920
Catagory                     Total    Private Shareable Shared
                         Pages KBytes  KBytes    KBytes KBytes
...
      Total Modules        794   3176     300         0   2876
      Total Dynamic Data   804   3216    3088         4    124
      Total System          49    196     196         0      0
Grand Total Working Set   1647   6588    3584         4   3000

Now we know that:

• Even without CDS feature turned on, there is about 3 MB of memory shared by all JVM processes. This shared memory is resulted from DLL files used by JVM like: jvm.dll, java.dll, ntdll.dll, kernel32.dll, etc.
• LongSleep.java application only need about 3.5 MB of private memory to run, which is about half of the total memory reported by Windows Task Manager.

Now let's repeat the same test with CDS turned on:

(Open first command window)
C:\>\progra~1\java\jdk1.6.0_02\bin\java -cp . -Xshare:on
   LongSleep
 Free memory: 4997088
Total memory: 5177344

(Open second command window)
C:\>\progra~1\java\jdk1.6.0_02\bin\java -cp . -Xshare:on
   LongSleep
 Free memory: 4997088
Total memory: 5177344

(Open third command window)
C:\>tasklist
Image Name       PID Session Name Session# Mem Usage
============= ====== ============ ======== =========
...
java.exe        1772                     0   7,032 K
java.exe         420                     0   7,032 K
(tasklist.exe reports the total memory usage 
   in the same way as Windows Task Manager)

C:\>\progra~1\resour~1\vadump -o -s -p 1772
Catagory                     Total    Private Shareable Shared
                         Pages KBytes  KBytes    KBytes KBytes
...
      Total Modules        784   3136     300         0   2836
      Total Dynamic Data   925   3700    2124         4   1572
      Total System          59    236     236         0      0
Grand Total Working Set   1768   7072    2660         4   4408

C:\>\progra~1\resour~1\vadump -o -s -p 420
Catagory                     Total    Private Shareable Shared
                         Pages KBytes  KBytes    KBytes KBytes
...
      Total Modules        784   3136     300         0   2836
      Total Dynamic Data   925   3700    2124         4   1572
      Total System          59    236     236         0      0
Grand Total Working Set   1768   7072    2660         4   4408

Comparing with CDS turned off, the results show that:

• The shared memory has been increased from 3000 KB to 4408 KB. The increased shared memory amount 1408 KB was mainly coming from the Dynamic Data catagory, which is probably how the CDS shared archive file was used by JVM processes.
• Of course, turning on the CDS feature costed bout 7072 - 6588 = 484 KB extra memory usage.
• The net saving on private memory usage is about 1408 - 484 = 924 KB, or 3584 - 2660 = 924 KB.

Part:   1  2  3 

This site Web