RFR: 8218675: Reduce verification overhead in ClassFileParser

[Claes Redestad]

On 2019-02-11 10:07, Claes Redestad wrote:
> 
> 
> On 2019-02-11 09:44, David Holmes wrote:
>>
>>> All of the modified UTF8-encoded bytes UTF8::next would skip over will
>>> have values >= 128 (assuming legal UTF-8, which UTF8::next already 
>>> assumes), so they can't match the special characters we're looking 
>>> for anyway, so the switch will never match any of them. Thus the new 
>>> method
>>> is semantically equivalent, but measurably faster.
>>
>> New code compares p1, p2, p3 ... to each of the special characters to 
>> see that it doesn't match. Or are you saying the switch somehow 
>> generates a set of range checks rather than comparisons??
> 
> No, I'm saying that any byte value that would have been skipped over by
> UTF8::next will be skipped over by the switch, since they are all 128
> and higher. It's impossible that, say, a ';' hides in one of the bytes
> of a codepoint.
> 
> UTF8 was designed to allow scanning for ASCII characters byte-by-byte
> like this, and modified UTF-8 is no different except for '\0' (which we
> don't care about here).

If you were just questioning the performance results, GCC does compile
the switch prelude in this method to a quick range check:

sub $0x2e,%ecx  // 2e is '.', the lowest character
cmp $0x2d,%cl   // 2e + 2d is '[', the highest character
ja ...

The most common range of characters, a-z, is outside of this range: for
all these we do one subtraction and a compare + branch in the common
case, compared to the baseline which did at least two branches per byte.

Specifically, this optimization amounts to ~100k fewer instructions on
startup even with -Xverify:none, a large chunk of which were cmp + jump.

/Claes