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::change_sig_to_verificationType seems to spend a lot of time creating the temporary symbols:

 ClassVerifier::change_sig_to_verificationType seems to copy the symbols a lot:
  +- 30.740 (9%) ClassVerifier::change_sig_to_verificationType(SignatureStream*,VerificationType*,Thread*)
  | +- 15.070 (4%) SignatureStream::as_symbol(Thread*)
  | +- 14.850 (4%) ClassVerifier::create_temporary_symbol(const Symbol*,int,int,Thread*)

This seems to be an offending piece of code:

inline int ClassVerifier::change_sig_to_verificationType(
    SignatureStream* sig_type, VerificationType* inference_type, TRAPS) {
  BasicType bt = sig_type->type();
  switch (bt) {
    case T_OBJECT:
    case T_ARRAY:
      {
        Symbol* name = sig_type->as_symbol(CHECK_0);
        // Create another symbol to save as signature stream unreferences
        // this symbol.
        Symbol* name_copy =
          create_temporary_symbol(name, 0, name->utf8_length(), CHECK_0);
        assert(name_copy == name, "symbols don't match");
        *inference_type =
          VerificationType::reference_type(name_copy);
        return 1;
      }

...and it comes from a mammoth changeset:

$ hg log -r 2062
changeset: 2062:3582bf76420e
user: coleenp
date: Thu Jan 27 16:11:27 2011 -0800
summary: 6990754: Use native memory and reference counting to implement SymbolTable
 
I think we need to reconsider how we manage symbol lifecycle to evade unreferencing without doing a copy.