RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent
jiangli.zhou at oracle.com
Mon Oct 22 17:57:34 UTC 2018
On 10/21/18 6:15 PM, Ioi Lam wrote:
> Re-sending to the correct mailing lists. Please disregard the other
> 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
> - field offsets computed in JavaClasses::compute_offsets
> - the layout of the strings objects in the shared strings table
> 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
> > should be tested.
> > 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.
This is for pre-resolving more constant pool references (to system
> - Ioi
More information about the serviceability-dev