RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all platforms [v4]

[David Holmes]

On Thu, 23 Feb 2023 12:46:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> I found one call to `add_to_hierarchy()` where we previously did not
>> grab in `Compile_lock` in `vmClasses::resolve_shared_class()` and
>> that call is made with this assert in place:
>> ```assert(!Universe::is_fully_initialized(), "We can make short cuts only during VM initialization");```
>> 
>> so it looks to me like we have a locking issue there (as in too early for locks).
>
> I think you are taking about CDS dump process. It works fine taking the lock.
> I think this was just some micro-optimization. But we should not mark and do deopt fixed that.

To restate: the assert_locked_or_safepoint is pointless because you just took out the lock here.

The code Dan points to does not seem to be related to CDS dump:

bool vmClasses::resolve(vmClassID id, TRAPS) {
  InstanceKlass** klassp = &_klasses[as_int(id)];

#if INCLUDE_CDS
  if (UseSharedSpaces && !JvmtiExport::should_post_class_prepare()) {
    InstanceKlass* k = *klassp;
    assert(k->is_shared_boot_class(), "must be");

    ClassLoaderData* loader_data = ClassLoaderData::the_null_class_loader_data();
    resolve_shared_class(k, loader_data, Handle(), CHECK_false);
    return true;
  }
#endif // INCLUDE_CDS

I remain concerned this code may be executed at a safepoint and we will now try to take the Compile_lock.

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

PR: https://git.openjdk.org/jdk/pull/12585