Hi Ioi,
The following call is probably slower than before because it involves
reading from a jar file.
cfs = FileMapInfo::open_stream_for_jvmti(ik, CHECK_NULL);
It is probably ok since the above is called under the following condition:
if (JvmtiExport::should_post_class_file_load_hook())
Minor comments in the following 2 files:
filemap.cpp
1494 assert(path_index >= 0, "should be called for shared built-in
classes only");
Should the above be also checking (path_index <
ClassLoaderExt::app_class_paths_start_index())?
SpaceUtilizationCheck.java
106 throw new RuntimeException("Must have 5 consecutive, fully
utilized regions");
5 should be 4
thanks,
Calvin
On 2/11/19, 9:23 AM, Ioi Lam wrote:
http://cr.openjdk.java.net/~iklam/jdk13/8218751-dont-store-classfiles-in-cds.v01/
https://bugs.openjdk.java.net/browse/JDK-8218751
For JVMTI ClassFileLoadHook support, the CDS archive currently stores
the original classfile data of all archived classes.
However, this consists of over 30% of the archive size. Because all
original classfile data are already available in other files (such as the
JDK lib/modules file, or JAR files in the classpath), we can simply read
from these locations when needed by JVMTI.
For the default CDS archive (included as part of the JDK distribution),
the size is reduced from about 18.5MB to 12.1MB on Linux/x64.
Thanks
- Ioi
