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

[Alan Bateman]

On 20/06/2019 02:36, yumin qi 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.
>
cc'ing core-libs-dev as this proposal involves changes to the 
ClassLoader API that will require significant discussion. One initial 
concern is that it exposes the notion of "shared class" in the standard 
API. I'm also concerned about the reliance on the protection domain and 
changing existing defineClass methods to allow the class bytes be null. 
How does that work when CDS is disabled - are you expecting class loader 
implementation with go-faster stripes to retry a different defineClass 
with the class bytes? Ioi has had a number of proposals in this area 
(and I see he's added a comment to the bug) but we didn't converge on 
the right API so maybe it time to have another attempt at that issue first.

-Alan