Status of AppCDS

August Nagro augustnagro at gmail.com
Tue Oct 3 21:04:37 UTC 2017


Good article, thanks for sharing. I've also played around with Graal's
`native-image` tool to generate standalone binaries, and while it's the
fastest (hello world in .006ms) the tool can't compile JavaFX applications.

On Tue, Oct 3, 2017 at 10:51 AM Jiangli Zhou <jiangli.zhou at oracle.com>
wrote:

> Hi August,
>
> Just to add some info in addition to David’s response. CDS is continuously
> being enhanced since JDK 8.
>
> Regarding how CDS works with AOT, the shared archive generated by CDS can
> coexist with the AOT library and used by JVM at runtime. Here is a very
> informative blog wrote by Matthew Gilliard,
> http://mjg123.github.io/2017/10/02/JVM-startup.html. It gives examples of
> how to use CDS and AOT to improve startup time.
>
> Regards,
> Jiangli
>
>
> On Oct 2, 2017, at 7:29 PM, David Holmes <david.holmes at oracle.com> wrote:
>
> Moving to hotspot-runtime-dev and bcc'ing the discuss list.
>
> Hello Augusto,
>
> On 3/10/2017 7:25 AM, August Nagro wrote:
>
> Hello,
> Both Class Data Sharing (CDS) [1] and AppCDS [2] are very interesting but
> seemingly neglected features of the Java Platform, offering the ability to
> reduce startup time.
>
>
> AppCDS is under continual development and is not "neglected" at all.
>
> Class Data Sharing is the global cache stored in
> /lib/[arch]/server/classes.jsa, and circumvents long class-loading times by
> caching the JVM’s internal representation of system jars and memory-mapping
> them in during startup. The feature's documentation [1] has been updated
> for Java 9, but I have yet to see a JDK or JRE installation that can use it
> without manually generating the archive. In every case I've encountered,
> the file needs to first be created (and given appropriate access
> permissions) with admin access, and then generated by `java -Xshare:dump`.
>
>
> Yes you have to create the shared archive if not using a JRE installer.
> But that can be done by whomever deploys the JRE in your environment. My
> understanding is that, due to the format of the archive, a given archive is
> only guaranteed to beusable on the machine on which it was created.
>
> AppCDS extends the same feature to user libraries. It works well, but has
> been experimental since (before?) JDK 8 and is commercial.
>
>
> Not sure it is still considered "experimental" but it is still evolving.
> It is a commercial feature in Java 9 but will not be in the future:
>
> http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
>
> Java has been criticized for its slow startup times. Improvements would
> enable command line utilities, the realistic use of JShell .jsh scripts
> (currently takes >4 seconds for hello world on my Mac [3]), and other
> applications. I'm not sure how *CDS concerts with other OpenJDK efforts
> like AOT compilation, but it offers the advantage of architecture
> independency and the ability to be shared across multiple JVMs.
>
>
> An archive can be shared across multiple JVMs on the same machine.
>
> Is *CDS doomed for deprecation, or will it be improved? Without work to CDS
> or changes to AppCDS, the current state is not very usable.
>
>
> *CDS has been constantly improved over the last few releases and continues
> to be improved for the next versions of the platform.
>
> Regards,
> David Holmes
>
> Regards,
> August Nagro
> [1]: https://docs.oracle.com/javase/9/vm/class-data-sharing.htm
> [2]:
>
> http://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-31503FCE-93D0-4175-9B4F-F6A738B2F4C4
> [3]:
> Executing command `jshell helloworld.jsh`, with file containing
> ```
> System.out.println("hello world");
> /exit
> ```
>
>
>


More information about the hotspot-runtime-dev mailing list