-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b34
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8083041 | emb-9 | Harold Seigel | P4 | Resolved | Fixed | b34 |
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.
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.
- backported by
-
JDK-8083041 ClassVerifier::verify_exception_handler_targets reconstructs the ExceptionTable in a loop
-
- Resolved
-
- relates to
-
JDK-8053904 JVM Warmup: Investigate class installation overhead
-
- Closed
-