[10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine
Claes Redestad
claes.redestad at oracle.com
Wed Mar 1 17:11:40 UTC 2017
Hi Aleksey!
On 03/01/2017 03:40 PM, Aleksey Shipilev wrote:
> On 03/01/2017 04:34 PM, Claes Redestad wrote:
>> the properties line reader has some relevance to startup, e.g.,
>> when reading the java.security file, and as more documentation
>> content has been added to this file it has been made apparent
>> that the handling of comment lines is inefficient due to treating
>> every character after a comment line marker ('#' or '!') as any
>> other character (writes it to an internal buffer etc) when a
>> fast-path consuming the rest of the line would do.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176041
>> Webrev: http://cr.openjdk.java.net/~redestad/8176041/jdk.01
> The idea looks fine.
>
> I think you can go further and unswitch the loop, saving branch in a hot loop,
> and using byte comparisons (may require some work to do efficient byte-char
> comparisons):
>
> if (inStream != null) {
> while (inOff < inLimit) {
> byte b = inByteBuf[inOff++];
> if (b == '\n' || b == '\r' || b == '\\') {
> break;
> }
> }
> } else {
> while (inOff < inLimit) {
> c = inCharBuf[inOff++];
> if (c == '\n' || c == '\r' || c == '\\') {
> break;
> }
> }
> }
Sure, with a bit of fix-up this drops another 170k executed bytecodes
to read in the java.security file (original: 1882k, now: 980k):
http://cr.openjdk.java.net/~redestad/8176041/jdk.02/
It seems javac optimizes byte-char comparisons pretty well in this
case since the chars we're comparing against are all in the 0-127 range,
so I don't think there's much we can do:
256: getfield #7 // Field inByteBuf:[B
259: aload_0
260: dup
261: getfield #5 // Field inOff:I
264: dup_x1
265: iconst_1
266: iadd
267: putfield #5 // Field inOff:I
270: baload
271: istore 9
273: iload 9
275: bipush 10 <- '\n'
277: if_icmpeq 294
280: iload 9
282: bipush 13 <- '\r'
284: if_icmpeq 294
287: iload 9
289: bipush 92 <- '\\'
Thanks!
/Claes
>
> Thanks,
> -Aleksey
>
More information about the core-libs-dev
mailing list