J
jeanlutrin
Hi all,
I made some tests with the new "Class Data Sharing" function
provided by the JVM (since version 1.5.0 / 5.0) and decided
to share my class data sharing discoveries with the group
(this topic is not often discussed here).
The tests were made on an Un*x system (Linux Fedora Core 3).
First of all, the performance gain is very real, especially
when launching lots of small apps.
Basically, it comes down to using the parameter/value
"-Xshareff", "-Xsharen" or "-Xshare:auto" (which is
the default) when calling the JVM.
The command line: "java -Xshare:dump" can be used to
force the creation of the memory-mapped archive file
(the shared classes). (btw this step is apparently
necessary on some Un*x systems!?. My system would
/not/ default to using the sharing, I had to
-Xshare:dump once and then add -Xsharen to force my
application sharing the classes.)
I had some "text file utilities" I wrote in Java which I'm
used to call from the command line (or from shell scripts).
This is clearly one area where the JVM's startup time
is a problem. I noticed gain of about 30% in this case
(using a non-scientific approach repeated many case, with
and without CDS).
If the JVM is installed in userland, each user will have his
own "cached" file (classes.jsa, about 11 Mb on my machine).
If only one JVM is installed for all the users, all the
users will share the same classes.jsa file (JSA for "Java
Shared Archive").
It may be possible to force different identical JVM
installed in different userland to use the same classes.jsa
but I didn't try to do this (simply copying the classes.jsa
file from one user on top of the classes.jsa file of another
user doesn't work, although the files have the same
length [but different checksums]).
I was pleasingly surprised by those first results and I
decided to force all my apps to use the JVM 1.5.0 and its
class data sharing feature, including IntelliJ IDEA (which
comes with its own JRE and refuse to run with an 1.5 JRE
without some hacking).
After days of "switching" to an 1.5 JVM and forcing all my
apps to use class data sharing, I can tell that overall
everything "Java related" is a little bit more responsive.
It is particularly noticeable when calling Java utilities
from the command line (which is no surprise) but also when
running unit tests (I tend to launch my test(s) quite often).
The memory footprint is also reduced compared to 1.4.2
(when running several apps).
I'm curious about your results too
See you all very soon (and "hi" to the c.l.j.p. regular
I met on freenode's #java saturday ,
Jean
P.S : If I understood correctly, Apple made their
own class data sharing "hack" for Java (way before 1.5)
and Sun basically copied their "idea". Whatever... This
means that developers using MacOS X benefits automagically
from "class sharing" since quite some time and have
nothing particular to do in order to use it.
I made some tests with the new "Class Data Sharing" function
provided by the JVM (since version 1.5.0 / 5.0) and decided
to share my class data sharing discoveries with the group
(this topic is not often discussed here).
The tests were made on an Un*x system (Linux Fedora Core 3).
First of all, the performance gain is very real, especially
when launching lots of small apps.
Basically, it comes down to using the parameter/value
"-Xshareff", "-Xsharen" or "-Xshare:auto" (which is
the default) when calling the JVM.
The command line: "java -Xshare:dump" can be used to
force the creation of the memory-mapped archive file
(the shared classes). (btw this step is apparently
necessary on some Un*x systems!?. My system would
/not/ default to using the sharing, I had to
-Xshare:dump once and then add -Xsharen to force my
application sharing the classes.)
I had some "text file utilities" I wrote in Java which I'm
used to call from the command line (or from shell scripts).
This is clearly one area where the JVM's startup time
is a problem. I noticed gain of about 30% in this case
(using a non-scientific approach repeated many case, with
and without CDS).
If the JVM is installed in userland, each user will have his
own "cached" file (classes.jsa, about 11 Mb on my machine).
If only one JVM is installed for all the users, all the
users will share the same classes.jsa file (JSA for "Java
Shared Archive").
It may be possible to force different identical JVM
installed in different userland to use the same classes.jsa
but I didn't try to do this (simply copying the classes.jsa
file from one user on top of the classes.jsa file of another
user doesn't work, although the files have the same
length [but different checksums]).
I was pleasingly surprised by those first results and I
decided to force all my apps to use the JVM 1.5.0 and its
class data sharing feature, including IntelliJ IDEA (which
comes with its own JRE and refuse to run with an 1.5 JRE
without some hacking).
After days of "switching" to an 1.5 JVM and forcing all my
apps to use class data sharing, I can tell that overall
everything "Java related" is a little bit more responsive.
It is particularly noticeable when calling Java utilities
from the command line (which is no surprise) but also when
running unit tests (I tend to launch my test(s) quite often).
The memory footprint is also reduced compared to 1.4.2
(when running several apps).
I'm curious about your results too
See you all very soon (and "hi" to the c.l.j.p. regular
I met on freenode's #java saturday ,
Jean
P.S : If I understood correctly, Apple made their
own class data sharing "hack" for Java (way before 1.5)
and Sun basically copied their "idea". Whatever... This
means that developers using MacOS X benefits automagically
from "class sharing" since quite some time and have
nothing particular to do in order to use it.