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, sometimes unconditionally the latter
- 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, and a switch improves it further (this code is exercised by some internal calls independently of whether -Xverify mode)
- skip_over_field_name calls both Character::isJavaIdentifierStart and Character::isJavaIdentifierPart for each unicode character
The superfluous copying is probably a remnants from an implementation when ClassFileParser called out to the separate verifier and had to be more conservative.
Fixing these issues add up to a 15% reduction of the bytecode verification overhead on a simple test running a Hello World with -Xshare:off -Xverify:all
- Symbol names are routinely copied into stack or heap allocated buffers, sometimes unconditionally the latter
- 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, and a switch improves it further (this code is exercised by some internal calls independently of whether -Xverify mode)
- skip_over_field_name calls both Character::isJavaIdentifierStart and Character::isJavaIdentifierPart for each unicode character
The superfluous copying is probably a remnants from an implementation when ClassFileParser called out to the separate verifier and had to be more conservative.
Fixing these issues add up to a 15% reduction of the bytecode verification overhead on a simple test running a Hello World with -Xshare:off -Xverify:all
- relates to
-
JDK-8218939 vm/mlvm/anonloader/stress/byteMutation crashed on windows
- Resolved