JAVA-5788 Improve ByteBufferBsonOutput::writeCharacters

[franz1981]

Fixes JAVA-5788

While running few benchmarks vs https://github.com/quarkusio/quarkus-super-heroes/blob/main/README.md using native image (graal CE) we found

writeCharacters heap-based code path to be bloated by:

• many not inlined calls: which Graal CE should be blamed since it has a very simple and naive inliner
• an excessive usage of logic to handle the current buffer to be used to write chars into
• zero loop unrolling due to the complexity of the main loop; since native image cannot profile branches cannot "shape" the assembly to grant latin to be a fast path

This patch is manually inlining the fast paths for both latin chars and heap buffers, assuming them to have enough available space.
This should help immensely JVM mode as well (i.e. JDK Hotspot) - so if there's any JMH bench I can re-use or run to verify it would be great.

NOTE: i could change the assumption which make the optimization to be triggered to be more "elastic" and use the heap buffers (byte[]) remaining capacity and perform checkpoints to refill it, too, but it would make the logic way more complex - still more elastic.
Let me know what you prefer 🙏

[franz1981]

@jyemin I see I have to open an issue there but I need a bit of help to find if there is already a JMH benchmark which already cover this; if there is not I can provides a new one myself

[franz1981]

This is a flamegraph coming from the same test running in JVM mode (JDK 21)

which reports a similar story.

[franz1981]

@jyemin I have just verified that since we are using the Netty driver as well, the core path there will uses (direct) Netty buffers too, so I think I will expand this optimization to include them, checking which optimization path is more appropriate there e g.

• branchless ASCII check with 8 chars (using 2 longs storing 4 UTF-16 chars each)
• branchless zero check leveraging ASCII bytes
• batch buffer writes

[franz1981]

I have added an extra commit to improve the case for the Netty buffers as well.
I can't modify the original JIRA, to explain and include such, how I can do it?

[franz1981]

I have tried hard to reduce the burden of Netty accessibility checks and the CPU cost of writing byte per byte with this, to not mention amortize the cost of branch mispredict for less common cases (non ASCII String).

[franz1981]

I have performed some JMH benchmarks and the Netty approach, despite is way better than the original code, is still much slower than the plain array case, byte per byte; I will experiment a bit more by using some Netty internalNioBuffer's API - although, since we create a Netty swapped wrapper (not needed actually) it could not work

[franz1981]

I've added ff360c0 to show what means using the internal NIO buffer from Netty
I'll post some JMH bench results soon - although native image CE won't benefit a lot from this since NIO ByteBuffer(s) have some "wide" enough OOP hierarchy which can still make single byte access to be too costly - which is something the "batchy" version instead was saving.