RFR 8059357: ClassVerifier redundantly checks constant pool entries multiple times

Harold Seigel harold.seigel at oracle.com
Fri Mar 22 14:43:27 UTC 2019


Please review this fix for JDK-8059357.  This fix improves how the 
verifier translates method signatures into verification types.  
Previously, the verifier did a separate signature translation for every 
invoke* instruction even if the method signature was the same as a 
previously translated signature.  With this change, the verifier, at the 
beginning of class verification, loops through the class's constant pool 
and translates each of the class's unique method signatures just once.  
Each signature's resulting verification types are stored as an entry in 
a hash table indexed by the signature's method_ref's Utf8 constant pool 

When verifying an invoke* instruction, the list of verification types is 
retrieved from the hash table and stack argument assignability is 
checked without having to translate the signature into its verification 
types.  Return types are handled similarly.

Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8059357/webrev/

JBS Bug:  https://bugs.openjdk.java.net/browse/JDK-8059357

The fix was regression tested by running Mach5 tiers 1 and 2 tests and 
builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on 
Linux-x64, and by running JCK-13 Lang and VM tests on Linux-x64.

(Thanks to Eric Caspole for running performance tests on this change.)

Thanks, Harold

More information about the hotspot-runtime-dev mailing list