RFR: 8278602: CDS dynamic dump may access unloaded classes

[Stefan Karlsson]

On Thu, 16 Dec 2021 03:46:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Cause of crash:
> 
> When dumping a CDS archive,  while iterating over entries of the `SystemDictionaryShared::_dumptime_table`, we do not check whether the classes are already unloaded. In the crash, we are trying to call `InstanceKlass::signer()` but the class has already been unloaded.
> 
> Fix:
> 
> Override the  template function `DumpTimeSharedClassTable::iterate` to ensure iteration safety.  Do not iterate over a class if its `class_loader_data` is no longer alive.
> 
> The assert in `DumpTimeSharedClassTable::IterationHelper` found another existing bug -- we were calling `SystemDictionaryShared::is_dumptime_table_empty()` without holding the `DumpTimeTable_lock`. I delayed the call until we have grabbed the lock.
> 
> Testing:
> 
> I have attached a test case into the bug report. Without the fix, it would reproduce the same crash in less than a minute. With the fix, the crash is no longer reproducible.
> 
> Unfortunately, the test case requires a ZGC patch (thanks to @stefank) that adds delays to  increase the likelihood of seeing unloaded classes inside the `_dumptime_table`. Therefore, I cannot integrate the test as a jtreg test. I'll mark the bug as **noreg-hard**

I've reviewed the interaction of the klasses in the _dumptime_table with the new is_loader_alive() check. I don't know the reset of the CDS code to know if the other changes are correct or not. I spotted something that looks weird:

src/hotspot/share/classfile/systemDictionaryShared.cpp line 194:

> 192:   _dump_in_progress = true;
> 193: }
> 194: 

Did you really intend to set _dump_in_progress to true in stop_dumping()? start_dumping() also sets it to true.

-------------

Changes requested by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6859