RFR(S) 8218751 Do not store original classfiles inside the CDS archive

[Jiangli Zhou]

Hi Ioi,

I'd like to understand the performance impact with this change. Do you have
any performance numbers  when JvmtiExport::should_post_class_file_load_hook()
is required? This is a performance vs footprint trade-off. For some users,
performance is more important than static footprint.

Could you also please provide some background/motivation for this change?

Thanks,
Jiangli

On Mon, Feb 11, 2019 at 9:24 AM Ioi Lam <ioi.lam at oracle.com> wrote:

>
> http://cr.openjdk.java.net/~iklam/jdk13/8218751-dont-store-classfiles-in-cds.v01/
> https://bugs.openjdk.java.net/browse/JDK-8218751
>
> For JVMTI ClassFileLoadHook support, the CDS archive currently stores
> the original classfile data of all archived classes.
>
> However, this consists of over 30% of the archive size. Because all
> original classfile data are already available in other files (such as the
> JDK lib/modules file, or JAR files in the classpath), we can simply read
> from these locations when needed by JVMTI.
>
> For the default CDS archive (included as part of the JDK distribution),
> the size is reduced from about 18.5MB to 12.1MB on Linux/x64.
>
> Thanks
>
> - Ioi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190212/872735a1/attachment-0001.html>