Class loading deoptimization checks scale devastatingly poorly

If you apply the prototype patch from JDK-8057967, and re-run and profile Nashorn doing the entire suite of benchmarks:

~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -jar ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/ext/nashorn.jar -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/run-octane.js

...then you will see this interesting subtree in profile:

150.180 Unsafe_DefineAnonymousClass
  + 133.480 SystemDictionary::parse_stream(Symbol*,Handle,Handle,ClassFileStream*,KlassHandle,GrowableArray<Handle>*,Thread*)
     + 133.480 Universe::flush_dependents_on(instanceKlassHandle)
         + 133.220 CodeCache::mark_for_deoptimization(DepChange&)
            +133.060 InstanceKlass::mark_dependent_nmethods(DepChange&)
               + 123.730 nmethod::check_dependency_on(DepChange&)
                  + 104.530 Dependencies::DepStream::spot_check_dependency_at(DepChange&)
   + 10.150 ClassFileParser::parseClassFile(Symbol*,ClassLoaderData*,Handle,KlassHandle,GrowableArray<Handle>*,TempNewSymbol&,bool,Thread*)

Here, one can see that out of 150 seconds spent in Unsafe.defineAnonymousClass, we spend >130 seconds looking for dependees on a newly-defined class.

The offending call is at:

void SystemDictionary::add_to_hierarchy(instanceKlassHandle k, TRAPS) {
  ...
  // Now flush all code that depended on old class hierarchy.
  // Note: must be done *after* linking k into the hierarchy (was bug 12/9/97)
  // Also, first reinitialize vtable because it may have gotten out of synch
  // while the new class wasn't connected to the class hierarchy.
  Universe::flush_dependents_on(k);
}