5

When a JRE is installed via an Oracle JRE installer, the installer creates a shared archive that enables class data sharing (CDS), reducing startup time and memory footprint of JRE processes.

Questions

If our installer instead installs a JRE by copying a JRE directory, do we lose class data sharing?

If so, can that be solved by regenerating the shared archive (using java -Xshare:dump) from our own installer?

Is there a mechanism in Java code to detect whether class data sharing is active or not?

Our install includes a shared archive (e.g., jre/bin/client/classes.jsa) that was presumably created on the original machine onto which we installed Java with the Oracle installer. Is this useful, harmless, or harmful?

Details

We're using Java 7. At least on some machines, we're using the HotSpot client VM.

Related questions

"Is the Java code saved in a Class Data Sharing archive (classes.jsa) compiled natively or is it bytecode?" - Accepted answer says native, but appears to be somewhat of a guess.

Community
  • 1
  • 1
Andy Thomas
  • 84,978
  • 11
  • 107
  • 151

1 Answers1

3

by copying a JRE directory, do we lose class data sharing?

Class data sharing file will be valid only if the JVM version and the boot classpath remains the same. Starting from 8u40 as a result of JDK-8046070 JVM will refuse to load CDS archive even if JRE directory is renamed or moved.

Java 7 still allows CDS archive to be reused when JRE directory is copied, but this is not a reliable feature and I would not recommend doing so.

can that be solved by regenerating the shared archive (using java -Xshare:dump)

Yes, that is a right way to go. This will ensure the integrity of generated CDS archive and also save the size of installation package.

Is there a mechanism in Java code to detect whether class data sharing is active or not?

Yes, by reading UseSharedSpaces flag with JMX:

    HotSpotDiagnosticMXBean bean = ManagementFactory.newPlatformMXBeanProxy(
            ManagementFactory.getPlatformMBeanServer(),
            "com.sun.management:type=HotSpotDiagnostic",
            HotSpotDiagnosticMXBean.class);
    System.out.println(bean.getVMOption("UseSharedSpaces"));

You may also force CDS requirement by -XX:+RequireSharedSpaces JVM flag.

"Is the Java code saved in a Class Data Sharing archive (classes.jsa) compiled natively or is it bytecode?"

Depends on what you mean by "compiled natively". Class metadata is saved in the native format specific to the concrete platform. But no bytecode is compiled. There is no ahead-of-time compilation, Java bytecode is saved in CDS archive as is.

apangin
  • 92,924
  • 10
  • 193
  • 247
  • Thank you! Does the absolute boot classpath need to be the same, or just the path relative to the JRE? (Also, note related question about the contents of the "private format," now linked in edited question above.) – Andy Thomas May 06 '15 at 02:49
  • @AndyThomas I've updated the answer with more details. – apangin May 06 '15 at 11:08
  • Thanks for the link to the Java 8 enhancements. I didn't see anything explicit there about refusing to load CDS archive if the JRE directory is renamed or moved. Does `bean.getVMOption("UseSharedSpaces")` report on whether class data sharing is *requested*, or *successful*? – Andy Thomas May 06 '15 at 16:36
  • @AndyThomas `UseSharedSpaces` tells whether CDS is actually used. – apangin May 06 '15 at 16:45
  • Thanks! Can you tell me where you're getting these details? – Andy Thomas May 06 '15 at 16:47
  • 1
    @AndyThomas From [HotSpot sources](http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/) and from my past experience (worked in HotSpot team some time ago). – apangin May 06 '15 at 17:04
  • At least in Eclipse, default access rules for rt.jar flag use of HotSpotDiagnosticMXBean as an error. A way to access the same HotSpot VM option through only public API is illustrated in the accepted answer in http://stackoverflow.com/questions/1880299/what-gc-parameters-is-a-jvm-running-with . – Andy Thomas May 06 '15 at 19:02