JacksonCodec should better guess the allocated buffer

[franz1981]

vert.x/src/main/java/io/vertx/core/json/jackson/JacksonCodec.java

Line 108 in 1f016f4

ByteBuf buf = Unpooled.buffer();

relies on default allocation, which is very small (256 bytes, but can be very big based on the actual need!). Subsequent reallocations, if any, will happen based on Netty default strategy, which is less then optimal, given that can quickly converge to very big values(see https://github.com/franz1981/netty/blob/4.1/buffer/src/main/java/io/netty/buffer/AbstractByteBufAllocator.java#L277 for what is doing now).

There are 4 different approaches here:

• use a thread local tmp buffer (or something similar to the striped pool implemented for Loom - Jackson buffer pool)
• use a chunked approach which have smaller chunks and perform a final copy into an exact sized Netty one based on the list
• like the previous, but creating a Composite ByteBuf out of the list of chunks (which is dangerous in case we have too many abstract implementations of Netty buffers flying around in core and hot path methods)
• perform a better guess for interesting types (eg JsonArray/JsonObject) - but can be easily O(N)

I don't know how much important is the codec I have mentioned but is the default choice from what I can tell.
I'll go deeper in the code in the next days and maybe there is a better way to improve this.

[franz1981]

Some other data points:

The Jackson generator is already making uses of a thread local BufferRecycler, already and:

• Unpooled::buffer is not what we want because end up calling LongAdder: it would be better to switch to unpooled vertx heap buffers instead (which are not ref cnt and accounting for LongAdder::incrementAndGet
• we can lazily let the jackson recycler to perform a single write over it, and allocate it once -> I'll send a PR soon for both