RFR: JDK-8222373 Improve CDS performance for custom class loaders

[Jiangli Zhou]

Hi Yumin,

Sorry for the late reply.

On Thu, Jun 20, 2019 at 10:01 AM yumin qi <yumin.qi at 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 <jianglizhou at 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.qi at 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