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.