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

[Jiangli Zhou]

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