Can UTF8StreamJsonParser#finishString be made faster with VarHandles?

[jpountz]

I was looking at UTF8StreamJsonParser#finishString which seems to mostly consist of scanning for a trailing quote, with an optimized code path for ASCII strings. This optimized code path for ASCII strings could be further optimized by using VarHandles to compare multiple bytes at once.

The current code looks like this:

        while (ptr < max) {
            int c = (int) inputBuffer[ptr] & 0xFF;
            if (codes[c] != 0) {
                if (c == INT_QUOTE) {
                    _inputPtr = ptr+1;
                    _textBuffer.setCurrentLength(outPtr);
                    return;
                }
                break;
            }
            ++ptr;
            outBuf[outPtr++] = (char) c;
        }

and could become something like:

private static final VarHandle VH_LE_LONG =
      MethodHandles.byteArrayViewVarHandle(long[].class, ByteOrder.LITTLE_ENDIAN);

[...]

        while (ptr <= max - Long.BYTES) {
            long next8Bytes = VH_LE_LONG.get(inputBuffer, ptr);
            if ((next8Bytes & 0x8080808080808080L) != 0) {
                // At least one of the bytes has the higher bit set, this is not a pure ASCII string
                break;
            }
            if (hasValue(next8Bytes, INT_QUOTE)) { // Implement hasValue based on https://graphics.stanford.edu/~seander/bithacks.html#ValueInWord
                // one of the next 8 bytes is a quote
                break;
            }
            // Maybe this loop can become unnecessary via https://github.com/FasterXML/jackson-core/issues/910
            for (int i = 0; i < Long.BYTES; ++i) {
              outBuf[outPtr + i] = (char) inputBuffer[ptr + i];
            }
            ptr += Long.BYTES;
            outPtr += Long.BYTES;
        }
        while (ptr < max) {
            int c = (int) inputBuffer[ptr] & 0xFF;
            if (codes[c] != 0) {
                if (c == INT_QUOTE) {
                    _inputPtr = ptr+1;
                    _textBuffer.setCurrentLength(outPtr);
                    return;
                }
                break;
            }
            ++ptr;
            outBuf[outPtr++] = (char) c;
        }

As VarHandles were introduced in Java 9, this would require releasing a MR JAR or bumping the min required version.

I haven't had a chance to measure if it made a significant difference but wanted to log the idea in case it gets someone's attention.

[pjfanning]

• looks like an interesting idea
• jackson-core is a MR jar (in 2.15 branch, at least - 2.14 and before are not MR jars) - only changed recently
• Jackson is a volunteer project so it would be best if someone volunteered to drive this
• if someone is using jmh to benchmark this - they should be careful to set the MR setting in the local jar - https://github.com/pjfanning/jackson-number-parse-bench does this

[cowtowncoder]

Sounds interesting, although I would not be too excited about multi-release jars (I know there's bit of that already for FastDoubleParser, but that's just merged in and not maintained as part of jackson-core).

When (... if) we finally get back to Jackson 3.0 work tho, baseline is probably going to be increased past Java 8 (at least 11 but I suspect by the time, 17 would be better choice) and that'd be be moot issue.

But as per @pjfanning's comments, what would really be interesting would be jmh benchmarking.

[cowtowncoder]

No plans to do in suggested form, closing. May re-file if a PR to be contributed.

[pjfanning]

@cowtowncoder I can look at this, maybe in the next few weeks. With Jackson 3 only supporting Java 17, we won't need separate code for different Java versions. I have been experimenting with similar changes in Apache Pekko.

[cowtowncoder]

@pjfanning Ok.

[pjfanning]

@cowtowncoder I had a look at the code and I'm not sure that this change is all that feasible.
I have some experiencing using the VarHandle approach to get long values from byte arrays and then seeing if the long value contains a certain byte.
The code in finishString is doing more than looking for a quote char. It is copying chars to another array while also validating against a 'codes' array. I think the code is better off as it is. The likelihood is that the Hotspot compiler does a good job of optimising this code path.

[cowtowncoder]

@pjfanning That's what I was thinking too -- changes to make use of bulk access would be huge, requiring basically full rewrite of decoder (or lots of code to sort of sync different access mechanisms).

[pjfanning]

@cowtowncoder I might still have a look anyway. One thing I would like to clarify is if the 'codes' array check is for validating that the bytes are valid for UTF-8?
The search for the quote char can be refactored. The array copy can be done in bulk using System.arraycopy. That just leaves rewriting the 'codes' array check.

The aim would be to do the refactor in PR and see if the tests still pass before then benchmarking against existing approach.

[cowtowncoder]

@pjfanning arrays is used for UTF-8 bytes to char decoding as well (length of byte seq for char, 1-3 bytes). System.arraycopy() would only work if refactoring not to use TextBuffer (or create alternate implementation).