Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8057845

ClassVerifier::verify_exception_handler_targets reconstructs the ExceptionTable in a loop

XMLWordPrintable

    • b34
    • Not verified

        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.

              hseigel Harold Seigel (Inactive)
              shade Aleksey Shipilev
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: