Improving AppCDS for Custom Loaders

[yumin qi]

HI, Jiangli

  Thanks for implementing the dynamic dump feature.
  I have some questions:
  1) Base archive. Is it only including boot images (java.base, rt.jar,
java.net ... )? Does it include  ext classes?
  2) The dump happens at the exit of application. There is maybe a case
that at exit, many classes already unloaded. If they are not in shared
archive and have big number, it will affect startup performance since they
will be loaded from source.
       So maybe, as you described in bug, copy the custom loader loaded
classes to shared space when they are first time loaded.
  3) What you refer to custom classes, do they include classes which are
loaded by app loader loaded classes?
  4) Does base archive take more space than (current) using class list
file? Not every class in base archive is used for an application, so I
support the other choice in your work ---- archive one for all (both base
and top layer).
  5) This should not be a question. dynamicDump, Can we give a short name
for command line option. No one (like me) like typing a long name with
Capital in it. Maybe ddump or dydump is enough?

--Yumin



On Mon, Dec 17, 2018 at 5:17 PM Jiangli Zhou <jiangli.zhou at oracle.com>
wrote:

> Hi Volker, Yumin and others,
>
> This is a follow up of our email discussions (back in May of this year)
> on improving AppCDS for custom class loaders. An umbrella RFE,
> JDK-8202854 (Hybrid archiving,
> https://bugs.openjdk.java.net/browse/JDK-8202854) was created in May to
> track the activities related to the topic. We have now started working
> on the final subtask (https://bugs.openjdk.java.net/browse/JDK-8207812)
> to implement dynamic archiving. There are some updates added to
> JDK-8207812. If you have any further feedback, please share with us
> (thanks!).
>
> With dynamic archiving, we can support custom class loaders more
> effectively. A class list is no longer needed when creating an AppCDS
> archive dynamically (during a java application execution). That gives us
> a potential to cleanup our code base and remove the experimental support
> for the custom loader's class list (mainly classListParser.cpp and
> classListParser.hpp). The cleanup can be staged after dynamic archiving
> is matured. Please let us know if you see any issues with the plan.
>
> Thanks!
>
> Jiangli
>
>