JDK-8057845 : ClassVerifier::verify_exception_handler_targets reconstructs the ExceptionTable in a loop
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-09-08
  • Updated: 2015-06-03
  • Resolved: 2014-09-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
9 b34Fixed
Related Reports
Relates :  
If one runs a classloader benchmark:

...with Nashorn-generated class files:

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

...one can produce this profile:

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:

I think we need to reconsider the approach of reconstructing the exception table on every loop iteration.
The re-fetching is no longer needed since Method no longer can get moved by GC (in 8 and 9).