RFR: 8274338: com/sun/jdi/RedefineCrossEvent.java failed "assert(m != __null) failed: NULL mirror"
David Holmes
dholmes at openjdk.java.net
Thu Oct 14 03:46:46 UTC 2021
On Wed, 13 Oct 2021 20:29:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> The MultiArray_lock isn't held when restoring shared arrays, so an observer can find one that isn't completely restored.
> Tested with tier1-3 in progress, and CDS tests locally. Not really reproduceable otherwise even with sleeps.
If the JVMTI code already acquires the lock to iterate through the classes then I can see why taking the lock in restore_unshareable_info might fix the observed problem. But that begs the question as to why JVMTI, as an observer, needs to take the lock in the first place, when these objects should not be observable until after they have been safely published? If the objects are not being safely published then other observers may also need to take out this lock. The real bug here seems to be that instanceKlasses can be found and inspected before InstanceKlass::restore_unshareable_info has been applied to that instanceKlass! Looking at Klass::restore_unshareable_info it has this:
// Add to class loader list first before creating the mirror
// (same order as class file parsing)
loader_data->add_class(this);
And that to me seems a bug as now the class can be found through the CLD before it is ready to be observed.
You fixed the current problem where JVMTI stumbles over a null mirror related to an array class, but what other inappropriately set data in the instanceKlass might it also look at?
-------------
PR: https://git.openjdk.java.net/jdk/pull/5935
More information about the hotspot-dev
mailing list