Improving AppCDS for Custom Loaders

Ioi Lam ioi.lam at
Thu May 10 23:05:18 UTC 2018

On 5/10/18 3:34 PM, Volker Simonis wrote:
> yumin qi <yumin.qi at <mailto:yumin.qi at>> schrieb am 
> Do. 10. Mai 2018 um 22:20:
>     Hi, Jiangli
>       Thanks for the info.
>     On Thu, May 10, 2018 at 11:39 AM, Jiangli Zhou
>     <jiangli.zhou at <mailto:jiangli.zhou at>> wrote:
>         Hi Yumin and Volker,
>         I’ve create an umbrella RFE JDK-8202854 to keep track this
>         effort. New sub-RFEs will be created and targeted for specific
>         JDK releases when each sub-item matures. Please refer to
>         JDK-8202854 for future progress.
>         Yumin, please see below for comments/questions.
>         > Agree not including objects in java heap at now --- thanks Jiangli for answering my question
>         in other thread.
>         I conclude from above that you are not using java heap object
>         archiving due to different GC algorithm being used(?).  I
>         would like to understand more about your GC choices. Could you
>         please provide more information on that? G1 GC is the default
>         GC in JDK. Thanks to our GC team, the performance of G1 has
>         been consistently improving over the recent JDK releases,
>         especially in JDK 9 and 10. I strongly encourage you to do
>         performance measurement/comparison and reevaluate your GC
>         choice if G1 is not used.
>     Most of our applications still using CMS, we are pushing to switch
>     to G1GC at this time but still most of them still with CMS. I know
>     CMS will be removed so it will not be your focus.
>         >   I think for #1, it does not conflict with the two layer
>         archive solution. We can skip the classes from base CDS
>         archive, only dump the non-base loaded classes into second
>         archive, this gives one more option for user to choose. Also
>         it will be good after dump archive to let the application
>         continue to run.
>         >
>         >   Can we do a Full GC before dump at exit? it may unload not
>         referenced classes, or it is not necessary since CDS wants to
>         resolve the startup performance for all loaded classes?
>         For classes loaded by the builtin loaders, they can be kept
>         alive when archiving phase start. For classes loaded by user
>         defined class loaders, we also need to prevent them from being
>         unloaded before archiving. I have a preliminary idea for how
>         to do that. I can share more information on that when it matures.
>     Yes, if classes with custom class loader cleaned, the class loader
>     itself will be purged. Full GC before exit may not be a good idea,
>     but we can skip unloading classes --- in case dump objects in java
>     heap.
> Why not dump the classes iteratively, while they are loaded. Class 
> loading time would be the most natural time for dumping a class, and 
> it‘s the time when we know the most about a class (i.e. full class bytes).

The archive is divided into RO/RW sections. Mutable metadata such as 
InstanceKlasses are stored in RW, while non-mutable ones such as 
ConstMethod and Symbol are stored into the RO section. In order to have 
a single section each for RW and RO, currently we load all the classes 
first, and then calculate the sizes of the 2 sections.

>     Thanks
>     Yumin

More information about the hotspot-runtime-dev mailing list