Loop fission: split ASCII fast path from multi-byte encoding in writeStringSegmentAsUTF8

[stalep]

Background

Richard Startin's loop fission article demonstrates that splitting loops with multiple distinct operations into separate loops allows C2 to optimize each loop more aggressively — vectorization, unrolling, and better register allocation. C2 does not perform loop fission automatically.

Current code

BytOutput.writeStringSegmentAsUTF8() fuses ASCII detection with byte writing in a single loop:

private void writeStringSegmentAsUTF8(String s, int start, int end) {
    int segLen = end - start;
    ensureCapacity(segLen * 3);
    for (int i = start; i < end; i++) {
        char c = s.charAt(i);
        if (c < 0x80) {
            buf[pos++] = (byte) c;           // ASCII fast path
        } else if (c < 0x800) {
            buf[pos++] = (byte) (0xC0 | (c >> 6));    // 2-byte UTF-8
            buf[pos++] = (byte) (0x80 | (c & 0x3F));
        } else if (Character.isHighSurrogate(c) && i + 1 < end) {
            // 4-byte UTF-8 surrogate pair
            ...
        } else {
            // 3-byte UTF-8
            ...
        }
    }
}

The multi-byte UTF-8 branches prevent C2 from vectorizing or aggressively unrolling the ASCII copy, even though for h5m's production data (93% strings, almost entirely ASCII), the branch is never taken for most strings.

Proposed optimization

Split into an ASCII scan + bulk copy, with a fallback for non-ASCII:

private void writeStringSegmentAsUTF8(String s, int start, int end) {
    ensureCapacity((end - start) * 3);
    // Scan for the end of the ASCII prefix
    int asciiEnd = start;
    while (asciiEnd < end && s.charAt(asciiEnd) < 0x80) asciiEnd++;
    // Bulk copy the ASCII prefix — tight loop with no branches
    for (int i = start; i < asciiEnd; i++) {
        buf[pos++] = (byte) s.charAt(i);
    }
    // Handle remaining non-ASCII characters (if any)
    if (asciiEnd < end) {
        writeStringSegmentAsUTF8Full(s, asciiEnd, end);
    }
}

The ASCII copy loop (buf[pos++] = (byte) s.charAt(i)) has no branches in the body — C2 can unroll it aggressively and potentially vectorize the copy. The multi-byte encoding is moved to a separate method that C2 optimizes independently.

Why this helps

From the Startin article: a fused loop "advances at the pace of the slowest operation." The multi-byte UTF-8 branches are the slowest operation — they prevent C2 from treating the loop as a simple copy. Splitting them out lets the ASCII loop run at full speed.

For h5m's production data:

• 93% of JSON values are strings
• Strings are almost entirely ASCII (field names, URLs, timestamps, metric names)
• Each string's writeStringSegmentAsUTF8 call would use the branchless ASCII loop
• Only strings with non-ASCII content (rare) fall through to the multi-byte path

What's already fissioned in jjq

jjq already applies loop fission in several places:

• needsEscaping() scans for escape chars, then escapeJson() does the escaping — two separate loops
• SWAR string scanning (parseStringBytes) scans for quote/backslash in bulk, then processes escapes separately
• SWAR whitespace skipping scans 8 bytes at a time, then falls back to scalar

This change would extend the fission pattern to the UTF-8 encoding path.

Expected impact

Low-medium. The existing serialization is already 60% faster than Jackson on 14MB production data. The benefit would be most visible for workloads with many short ASCII strings where the per-string writeStringSegmentAsUTF8 overhead is proportionally larger.

Should benchmark before and after to verify. The serialization path is not the primary bottleneck for h5m (parsing and query execution dominate).

Reference

• Richard Startin, Loop Fission, Nov 2021
• jjq issue Add JqValues.serializeToBytes(JqValue) method for byte[]-based serialization #43 (direct byte serialization)
• jjq issue SWAR-accelerate escapeJsonToBytes for materialized string serialization #57 (segment-based escapeJsonToBytes)

[stalep]

Analysis complete — two actionable findings, issue deferred for writeStringSegmentAsUTF8

Thorough review of all hot-path loops in jjq-core found only two candidates for loop fission/optimization:

1. JqArray.append() — manual copy loop → toArray() (ACTIONABLE)

// Current: per-element virtual dispatch via List.get(i)
JqValue[] arr = new JqValue[elements.size() + 1];
for (int i = 0; i < elements.size(); i++) {
    arr[i] = elements.get(i);
}

Can be replaced with elements.toArray(new JqValue[elements.size() + 1]) which uses System.arraycopy → JVM memcpy intrinsic. Eliminates per-element virtual dispatch.

2. BytOutput.writeStringSegmentAsUTF8() — ASCII fast-path split (DEFERRED)

The issue's original proposal. Analysis shows it's not on h5m's hot path:

• Deferred-bytes strings use zero-copy writeBytes() (line 252-258 in JqString) — 93% of strings
• Interned field names use pre-computed byte arrays — no writeStringSegmentAsUTF8
• Only fires for programmatically constructed strings (JqString.of, builder.put) and accessed deferred strings
• h5m's production data: 0% escape density, 100% ASCII, deferred-bytes dominance

Loops NOT candidates for fission:

Loop	Why not
JqObject.appendTo/appendToBytes serialization	Sequential output dependency (key before value)
JqObject.hashCode	Reduction with polymorphic dispatch — splitting worsens locality
BytOutput.escapeJsonToBytes	Already uses segment-based scan/flush pattern (effectively fissioned)
JqString.escapeJson	Same segment-based pattern
JqString.needsEscaping	Single operation (scan)
JqObject.of(Map)	Splitting would double iterator cost
VirtualMachine.runLoop	Dispatch loop, not data processing
Parser loops	Sequentially dependent (must parse in order)

Context from related issues:

• Issue Delegate parse(String) to parse(byte[]) to eliminate charAt profile pollution exposure #69: parse(String) now delegates to byte parser for ≤64KB, so String parser's charAt loops are largely bypassed
• Issue String.charAt profile pollution may affect jjq serialization in mixed Unicode/ASCII workloads #68: charAt profile pollution — the real threat to writeStringSegmentAsUTF8, but the fix is in Jackson/JVM, not in loop fission
• Issue Add varied-input benchmarks for escape handling and investigate branchless table approach #67: Escape benchmark showed 0% escape density in h5m production data — escape handling is not a bottleneck
• Issue SWAR-accelerate escapeJsonToBytes for materialized string serialization #57: escapeJsonToBytes already uses segment-based scanning (issue SWAR-accelerate escapeJsonToBytes for materialized string serialization #57 rewrite)

Recommendation: Keep issue open but low priority. Implement the JqArray.append() toArray fix separately (trivial). The writeStringSegmentAsUTF8 ASCII fast-path can be revisited if profiling shows it as a hotspot in a real workload.