RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent (original) (raw)

Ioi Lam ioi.lam at oracle.com
Mon Oct 22 01:11:57 UTC 2018

http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ https://bugs.openjdk.java.net/browse/JDK-8212200

Hi,

CDS has various built-in assumptions that classes loaded by SystemDictionary::resolve_well_known_classes must not be replaced by JVMTI ClassFileLoadHook during run time, including

The "well-known" classes can be replaced by ClassFileLoadHook only when JvmtiExport::early_class_hook_env() is true. Therefore, the fix is to disable CDS under this condition.

I have added a few test cases to try to replace shared classes, including well-known classes and other classes. See comments in ReplaceCriticalClasses.java for details.

As a clean up, I also renamed all use of "preloaded" in the source code to "well-known". They refer to the same thing in HotSpot, so there's no need to use 2 terms. Also, The word "preloaded" is ambiguous -- it's unclear when "preloading" happens, and could be confused with what CDS does during archive dump time.

In early e-mails Jiangli wrote:

We should consider including more classes from the default classlist in the test. Archived classes loaded during both 'early' phase and after should be tested.

Done.

For future optimizations, we might want to prevent loading additional shared classes if any of the archived system classes is changed.

What's the benefit of doing this? Today we already stop loading a shared class if its super class was not loaded from the archive.

Thanks

More information about the hotspot-runtime-dev mailing list