If one runs a classloader benchmark:
  http://cr.openjdk.java.net/~shade/8053904/benchmarks.jar

...with Nashorn-generated class files:
 http://cr.openjdk.java.net/~shade/8053904/classes.jar

...and jdk9 executed as:
 $ java -jar benchmarks.jar -wi 0 -i 30 -r 10s -p file=classes.jar

...one can produce this profile:
 http://cr.openjdk.java.net/~shade/8053904/class-install-calltree-2.txt

Looking closely at this profile, one can note an interesting thing: ClassVerifier::verify_exception_handler_targets seems to spend a lot of time reconstructing the exception table:
  +- 30.470 (9%) ClassVerifier::verify_exception_handler_targets(unsigned short,bool,StackMapFrame*,StackMapTable*,Thread*)
  | +- 11.350 (3%) ConstMethod::exception_table_length()const
  | +- 11.270 (3%) ConstMethod::exception_table_start()const

This seems to be an offending piece of code:

  ExceptionTable exhandlers(_method());
  int exlength = exhandlers.length();
  for(int i = 0; i < exlength; i++) {
    //reacquire the table in case a GC happened
    ExceptionTable exhandlers(_method());

...and this seems to be the history behind it:
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-June/003913.html

I think we need to reconsider the approach of reconstructing the exception table on every loop iteration.