RFR 8059357: ClassVerifier redundantly checks constant pool entries multiple times
Harold Seigel
harold.seigel at oracle.com
Fri Mar 22 18:16:24 UTC 2019
Hi Ioi,
Thanks for looking at this!
See comments inline.
On 3/22/2019 1:41 PM, Ioi Lam wrote:
> Hi Harold,
>
> This looks good overall. Thanks for making the verifier faster!
>
> Some comments:
>
> 2831 sig_as_verification_types* mth_sig_verif_types =
> *(method_signatures_table()->get(sig_index));
>
> How about calling the "get" method in a helper function, which asserts
> that the returned value is not NULL?
If I call translate_signature() on demand then the get(sig_index) call
will validly return NULL sometimes.
>
> 2999 for (int i = nargs; i < sig_verif_types_len; i++) {
> 3000 current_frame->push_stack(sig_verif_types->at(i),
> CHECK_VERIFY(this));
>
> For added safety, how about asserting that the second item, if exists,
> must be ITEM_Long_2nd or ITEM_Double_2nd?
Will do.
>
> Also, is there any reason why ClassVerifier::init_method_sigs_table
> must be done at the beginning? Is it possible to do the
> translate_signature() on demand? That way you'd save one loop overate
> each element in the constant pool.
Yes it is a good idea to call translate_signature() on demand. I'll
give it a try. It will also allowing getting rid of method_sig_count().
>
> If you decide to keep the separate loop, then maybe unique_sig_indexes
> doesn't need to be a growable array, because you already counted the
> _klass->method_sig_count()?
I used a GrowableArray to take advantage of its append_if_missing()
function but that won't be needed if done on demand.
Thanks! Harold
>
> Thanks
> - Ioi
>
> On 3/22/19 7:43 AM, Harold Seigel wrote:
>> Hi,
>>
>> 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 index.
>>
>> 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