RFR: 8218675: Reduce verification overhead in ClassFileParser

David Holmes david.holmes at oracle.com
Mon Feb 11 01:50:55 UTC 2019


Hi Claes,

On 9/02/2019 2:07 am, Claes Redestad wrote:
> Hi,
> 
> the code to verify method and field signatures in ClassFileParser has a
> number of inefficiencies:
> 
> - Symbol names are routinely copied into stack- or heap-allocated
> buffers.

These changes seem okay. I think you will find that with your changes 
as_utf8_flexible_buffer and it's helper as_C_string_flexible_buffer, are 
now dead code.

> - In verify_unqualified_name we unnecessarily test to detect non-ASCII
> characters: each byte in multi-byte characters will be over > 127, so
> it's faster to keep the loop simple. Rewriting as a switch improves it
> further (this code is exercised by some internal calls independent of
> -Xverify mode)

I don't see how this can be true. With the switch we will generate a 
test for every character against all 6 special characters. With the 
existing code we will bail out for non-ascii characters after one 
comparison.

> - skip_over_field_name has a slowpath for non-ASCII doing upcalls to
> both Character::isJavaIdentifierStart and 
> Character::isJavaIdentifierPart for each unicode character - which seems
> like a bug...

I agree there's a performance bug, but it only calls both if the 
character is not a legal identifier start character (so mainly 
inefficient when processing digits in names). But given we know if we're 
dealing with the first character it makes sense to make the change you made.

Thanks,
David
-----

> 
> Webrev: http://cr.openjdk.java.net/~redestad/8218675/open.00/
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8218675
> 
> The now superfluous copying is probably a remnant from a time when
> ClassFileParser called out to the separate verifier and had to be
> more conservative.
> 
> Fixing these issues reduces bytecode verification overhead by ~15%
> on a Hello World with -Xshare:off -Xverify:all.
> 
> Testing: tier1-3
> 
> Thanks!
> 
> /Claes


More information about the hotspot-runtime-dev mailing list