Bugzilla Bug 207282

Apparently there is something in Sun's JVM called "Class Data Sharing", which
involves preloading the rt.jar classes and writing a memory image of them down
to disk, which is later mmaped as read-only and thus able to be shared memory
between running VMs, with a view to saving memory across a system and (more to
the point) reducing start-up time for systems running `java -client`.

The referenced pages mention that Sun's "installer" builds classes.jsa on the
target machine at installation, but it describes the (undocumented) option to
build it yourself as necessary,

# java -client -Xshare:dump

It writes classes.jsa to the JRE's system directory, so you'll need to be root.

My own local testing showed a small but noticeable startup speed improvement.
Perhaps others could try this and report.

AfC

There's no Client VM for amd64 for example.

Nice idea though, we just need to come up with nice USE flag name + description
(the long description in metadata.xml would probably help here). The flag would
be obviously masked on amd64 because nelchael is right.

For what it's worth, by all appearances the thing just (politely) fails if the
VM doesn't support it (Try `java -server -Xshare:dump` to see what I mean);
could just include it in the ebuild; if it works it works, if not, no biggie.
Not so sure you need a whole USE flag for it.

Incidentally, more testing has shown the startup benefit is definitely
significant, and the simple fact of page sharing between VMs is exciting.

If you want to see it using the shared data, try:

$ java -client -verbose:class -Xshare:off HelloWorld

(ie, the normal state of affairs) vs

$ java -client -verbose:class -Xshare:on HelloWorld

(force it, and compare what it says when loading classes)

AfC

P.S. I've always forced my build and launcher systems to specify -client; most
people thought I was weird for it as it was the "default"; interestingly on my
current system the `java` front end has decided that -server is the default.

(In reply to comment #3)
> Not so sure you need a whole USE flag for it.

we would have to be able to support the default option, as we don't know the
side effects.  Plus we could always enable the flag by default and then ppl
could disable it if they really wanted to.

> 
> Incidentally, more testing has shown the startup benefit is definitely
> significant, and the simple fact of page sharing between VMs is exciting.
> 

Numbers, we need numbers  (well, I want numbers)


Poor me and my amd64 vms :(

For reference, here is some doco's

http://java.sun.com/javase/6/docs/technotes/guides/vm/class-data-sharing.html

(In reply to comment #5)
> For reference, here are some docs

That is the URL I put in the bug's URL field :)

AfC

Turns out that Sun's 1.6 JRE also supports Class Data Sharing for it's server
VM. (as I found out when I ran `java -Xshare:dump` and forgot to supply
`-client` onyl to have it succeed and write:

/opt/sun-jdk-1.6.0.04/jre/lib/i386/server/classes.jsa

Running again as `java -client -Xshare:dump` resulted in:

/opt/sun-jdk-1.6.0.04/jre/lib/i386/client/classes.jsa

being created. Huh.

AfC

I just noticed the emul-linux-x86-java:1.5 ebuilds do this, and a bit of search
revealed that we already did it in 1.5 JDK's (client only) until it disappeared
for some unknown reason in 1.5.0.09...

(In reply to comment #7)
> Turns out that Sun's 1.6 JRE also supports Class Data Sharing for it's server
> VM. (as I found out when I ran `java -Xshare:dump` and forgot to supply
> `-client` onyl to have it succeed and write:

Not on amd64 :(

gehinom ~ # GENTOO_VM=sun-jre-bin-1.6 java -Xshare:dump
Error occurred during initialization of VM
Dumping a shared archive is not supported on the Server JVM.
gehinom ~ # GENTOO_VM=sun-jre-bin-1.6 java -client -Xshare:dump
Error occurred during initialization of VM
Dumping a shared archive is not supported on the Server JVM.

But we can add it for x86.

OK, it's added in sun-jdk, sun-jre-bin (for x86) and the emul-linux package
(amd64). In 1.6 for both client and server, in 1.5 for client only. JRE's
already had it for client VM because the construct.sh script creates it - just
added to 1.6 JRE's for server VM. Moved it from construct.sh to the ebuild.