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
