[UNDERTOW-2210] Improved write ASCII path on ServletPrintWriter

[franz1981]

No description provided.

[franz1981]

Still WIP, I'll run some micro and end 2 end benchmark soon with the final implementation.

[franz1981]

@fl4via @stuartwdouglas
I've added a JMH benchmark (a bit unfair because it doesn't iterate through different strings), which results are (on my machine):

Benchmark                      (encoderType)  (inLength)  (outCapacity)  Mode  Cnt     Score    Error  Units
AsciiEncodingBenchmark.encode          batch           7           8196  avgt   20     0.025 ±  0.001  us/op
AsciiEncodingBenchmark.encode          batch          19           8196  avgt   20     0.044 ±  0.001  us/op
AsciiEncodingBenchmark.encode          batch         248           8196  avgt   20     0.255 ±  0.002  us/op
AsciiEncodingBenchmark.encode          batch       12392           8196  avgt   20    12.686 ±  1.038  us/op
AsciiEncodingBenchmark.encode          batch      493727           8196  avgt   20   488.882 ±  2.891  us/op
AsciiEncodingBenchmark.encode        noBatch           7           8196  avgt   20     0.025 ±  0.001  us/op
AsciiEncodingBenchmark.encode        noBatch          19           8196  avgt   20     0.042 ±  0.001  us/op
AsciiEncodingBenchmark.encode        noBatch         248           8196  avgt   20     0.409 ±  0.001  us/op
AsciiEncodingBenchmark.encode        noBatch       12392           8196  avgt   20    17.131 ±  0.133  us/op
AsciiEncodingBenchmark.encode        noBatch      493727           8196  avgt   20   706.596 ±  6.517  us/op
AsciiEncodingBenchmark.encode        vanilla           7           8196  avgt   20     0.026 ±  0.001  us/op
AsciiEncodingBenchmark.encode        vanilla          19           8196  avgt   20     0.052 ±  0.001  us/op
AsciiEncodingBenchmark.encode        vanilla         248           8196  avgt   20     0.546 ±  0.006  us/op
AsciiEncodingBenchmark.encode        vanilla       12392           8196  avgt   20    28.323 ±  0.216  us/op
AsciiEncodingBenchmark.encode        vanilla      493727           8196  avgt   20  1089.093 ± 26.762  us/op

I didn't yet spend time into profiling (with perf) to see if bound check elimination has been effective and I still need to run a full fat end 2 end test with SpecJ, but code-wise, should be a in a decent state for a review.

[carterkozak]

👋 Hi there, @franz1981 :-)

Out of curiosity, how do the benchmarks above compare to some variation of ByteBuffer.put(string.getBytes(StandardCharsets.US_ASCII))? (relevant blogpost from Claes Redestad: https://cl4es.github.io/2021/10/17/Faster-Charset-Encoding.html -- I realize the allocation will have broader impact, but I'm curious about the comparison point!)

[franz1981]

For smaller strings is very likely will perform better then what I have done, but not fully sure; let me do it, I am curious too
And Hi sir @carterkozak 😁 I was sure I would have triggered you eheh

[franz1981]

And I didn't tried with varhandle byte buffer view (that will save, likely the reverse bytes due to endianess)

[franz1981]

Results from SpecJ are very good: as expected it deliver a reduction of overhead ~2X
ie from 2.91% to 1.43% of cpu samples presence for the overall test duration and, for the specific stack trace related JSP
from 51.82% to 31,19% that's still very good.
I'll double check the ASM of JMH to see if there's anything better thanks to var handle byte buffer view and a comparison with lang encoders as I've promised to @carterkozak

[franz1981]

Interestingly, JDK 19 (note: prev results were using JDK 11) seems to disagree:

Benchmark                      (encoderType)  (inLength)  (outCapacity)  Mode  Cnt    Score    Error  Units
AsciiEncodingBenchmark.encode          batch           7           8196  avgt   20    0.020 ±  0.001  us/op
AsciiEncodingBenchmark.encode          batch          19           8196  avgt   20    0.041 ±  0.001  us/op
AsciiEncodingBenchmark.encode          batch         248           8196  avgt   20    0.253 ±  0.013  us/op
AsciiEncodingBenchmark.encode          batch       12392           8196  avgt   20   12.771 ±  0.574  us/op
AsciiEncodingBenchmark.encode          batch      493727           8196  avgt   20  499.805 ± 11.393  us/op
AsciiEncodingBenchmark.encode        noBatch           7           8196  avgt   20    0.019 ±  0.001  us/op
AsciiEncodingBenchmark.encode        noBatch          19           8196  avgt   20    0.025 ±  0.001  us/op
AsciiEncodingBenchmark.encode        noBatch         248           8196  avgt   20    0.161 ±  0.004  us/op
AsciiEncodingBenchmark.encode        noBatch       12392           8196  avgt   20    8.856 ±  0.095  us/op
AsciiEncodingBenchmark.encode        noBatch      493727           8196  avgt   20  329.699 ±  1.925  us/op
AsciiEncodingBenchmark.encode        vanilla           7           8196  avgt   20    0.021 ±  0.001  us/op
AsciiEncodingBenchmark.encode        vanilla          19           8196  avgt   20    0.035 ±  0.001  us/op
AsciiEncodingBenchmark.encode        vanilla         248           8196  avgt   20    0.303 ±  0.007  us/op
AsciiEncodingBenchmark.encode        vanilla       12392           8196  avgt   20   19.122 ±  0.039  us/op
AsciiEncodingBenchmark.encode        vanilla      493727           8196  avgt   20  722.313 ± 59.218  us/op

and report the first commit of this PR to be the winner by some margin.

Still on JDK 19 using a VarHandle to write LittleEndian long data into the buffer instead, makes batch to be near the winner:

Benchmark                      (encoderType)  (inLength)  (outCapacity)  Mode  Cnt    Score    Error  Units
AsciiEncodingBenchmark.encode          batch           7           8196  avgt   20    0.019 ±  0.001  us/op
AsciiEncodingBenchmark.encode          batch          19           8196  avgt   20    0.033 ±  0.001  us/op
AsciiEncodingBenchmark.encode          batch         248           8196  avgt   20    0.185 ±  0.017  us/op
AsciiEncodingBenchmark.encode          batch       12392           8196  avgt   20    9.273 ±  0.511  us/op
AsciiEncodingBenchmark.encode          batch      493727           8196  avgt   20  384.584 ± 10.149  us/op

For reference, VarHandle is very bad on the same encoder type with JDK 11:

Benchmark                      (encoderType)  (inLength)  (outCapacity)  Mode  Cnt    Score   Error  Units
AsciiEncodingBenchmark.encode          batch           7           8196  avgt   20    0.029 ± 0.001  us/op
AsciiEncodingBenchmark.encode          batch          19           8196  avgt   20    0.045 ± 0.001  us/op
AsciiEncodingBenchmark.encode          batch         248           8196  avgt   20    0.275 ± 0.015  us/op
AsciiEncodingBenchmark.encode          batch       12392           8196  avgt   20   14.635 ± 0.582  us/op
AsciiEncodingBenchmark.encode          batch      493727           8196  avgt   20  608.942 ± 6.466  us/op

performing even worse then the ByteBuffer version

[franz1981]

I believe this can be made even faster by reading chars as long via varhandle/methodhandle, will experiment with it next week.
I was hoping it was using SIMD to read chars into long already but verified that was just spilling (advice was coming from Richard Startin)

[franz1981]

@theRealAph I've removed

            final long maskedBatch1 = (batch1 & 0x007f_007f_007f_007fL) << 8;
            final long maskedBatch2 = batch2 & 0x007f_007f_007f_007fL;
            final long batch = maskedBatch1 | maskedBatch2;

because of the previous check re being in [0, 127]

[franz1981]

@fl4via this is now ready for review; it delivers a great speedup (up to 2X) across different JDK versions (11->19)

[ropalka]

Thanks @franz1981 !

[franz1981]

Thanks @ropalka !!!

[franz1981]

Placing this comment here to remember: https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L52 shows that whatever single byte char is fine, meaning 0-255 too!
This translate in a wider encoding domain (Windows-1252 which is a superset of ISO 8859-1, also called ISO Latin-1) then what we've used in undertow (and not only, it seems).
TLDR we can still perform the super fast path of single-byte encoding till 255 included and not just 127 (and the check mask of this optimized method should change accordly!)