RFR: 8274338: com/sun/jdi/RedefineCrossEvent.java failed "assert(m != __null) failed: NULL mirror"

[Ioi Lam]

On Thu, 14 Oct 2021 03:43:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> 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?

Yes, I agree that's fishy. But I think the bug may not be the call to add_class. If you look at ClassFileParser::fill_instance_klass(), it also does this very early, before many fields of the class are initialized:


  const bool publicize = !is_internal();
  _loader_data->add_class(ik, publicize);


whereas Klass::restore_unshareable_info always uses publicize==true. Could that be an issue?

Also, when a class is parsed, the mirror is created almost at the very end. However, for archived classes, the mirror is created when only the Klass portion are initialized. Maybe we should delay the mirror creation to a later time?

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

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