Hi Yumin, Sorry for the late reply.
On Thu, Jun 20, 2019 at 10:01 AM yumin qi <yumin...@gmail.com> wrote: > > HI, Jiangli > > Thanks for your comments. > Yes, the implementation may land on adding a public API. > Are the custom loaded classes treated well enough now with dynamic > dump/share? I haven't checked that recently. Unfortunately, the answer is no for both static and dynamic dumping. For static dumping using a classlist without runtime execution, we need a workable solution with a simplified classlist format that can be automatically generated by the VM without any additional processing tool(s). It's possible preloading an entire JAR file for a user defined classloader is a better approach. Doing research on the different usage cases in real world applications will help understand the requirements and design a clean solution for this. I'll help look into the usage patterns. The dynamic dumping implemented in JDK 13 also doesn't fully support user defined classloader yet. If a classloader and all loaded classes are unloaded before dumping, then all data are lost and cannot be archived. A simple approach to address that issue is to retain the classloader, which might cause side-effects. So that was not included in JDK 13 dynamic archiving implementation. Another solution is to copy data during creation time. For both static and dynamic dumping, we also need to consider how to handle multiple instances for a classloader. Best regards, Jiangli > > Thanks > Yumin > > On Thu, Jun 20, 2019 at 8:08 AM Jiangli Zhou <jiangliz...@google.com> wrote: >> >> Hi Yumin, >> >> Moving away from re-reading class byte stream and re-computing CRC at >> runtime is definitely in the right direction. That will make CDS user >> defined class loader support become beneficial. >> >> To make the user defined class loader support usable, the following >> two areas need to be redesigned: >> >> 1) Class Loader API, I see Alan also brought that up in his reply >> A new archive-aware class loader should be introduced to assist >> CDS. That will help design a cleaner set of APIs. It will also make >> CDS implementation cleaner in this area. >> >> 2) Dumping process >> This is for both the static dumping process and dynamic dumping >> process. For the static dumping process, a complete new design is >> needed in order to make the support adoptable. >> >> Best regards, >> >> Jiangli >> >> On Wed, Jun 19, 2019 at 6:37 PM yumin qi <yumin...@gmail.com> wrote: >> > >> > Hi, Please review: >> > bug: https://bugs.openjdk.java.net/browse/JDK-8222373 >> > webrev: http://cr.openjdk.java.net/~minqi/8222373/01/ >> > >> > To load shared class from CDS, first class file stream is read from jar >> > file, then load the class with the stream. In vm, the stream is used to >> > calculate file size and crc32 which are used to compare with the counter >> > parts stored in CDS. >> > >> > In fact, when CDS mapped, every SharedClassPathEntry is checked for >> > validation, if there is mismatch JVM will exit. That is, if user updated >> > jars and did not recreated CDS archive, it would fail. This can make us >> > load the class from CDS directly (if it is in CDS) without checking class >> > file length and crc32, so skip getting byte stream from source to save >> > time. >> > >> > Tests: submit passed >> > local on linux-x86_64: jtreg/runtime >> > >> > >> > Thanks >> > Yumin
