Enhance buffer handling to reduce direct list access.

[vbabanin]

Summary

The PR improves buffer handling by introducing a currentByteBuffer field to cache the current ByteBuf, reducing direct list access which is costly because of bounds checking. Additionally, caching currentByteBuffer helps with JIT (Just-In-Time) inlining based on compilation profiling. By making the buffer access more predictable and, the JIT compiler can better inline the getCurrentByteBuffer method, leading to improved runtime performance.

Test Name	Base Mean	Compare Mean	Perf Diff Percent	Z-Score
Deep BSON Encoding	62.2417	71.5916	15.02%	6.7074
Flat BSON Encoding	133.9693	172.8321	29.01%	10.3677
Full BSON Encoding	139.8435	172.5080	23.36%	20.1526
Large doc Client BulkWrite insert	56.1605	62.9421	13.57%	12.0393
Large doc Collection BulkWrite insert	62.0188	72.3853	16.71%	17.0376
Large doc bulk insert	60.6105	70.3881	16.13%	15.0138
Large doc insertOne	63.2810	73.0264	15.40%	11.1243

Perf analyzer results: Link

JAVA-5846

[katcharov]

LGTM. Let's add a secondary.

[nhachicha]

LGTM shouldn't we release the cached buffer when calling close? (the underlying Native C/C++ buffer could be reference counted and needs to drop to 0 to actually free the memory)

[vbabanin]

LGTM shouldn't we release the cached buffer when calling close? (the underlying Native C/C++ buffer could be reference counted and needs to drop to 0 to actually free the memory)

In this case, currentByteBuffer is already part of bufferList, and we don’t retain any additional reference once it's cached, so it should be released as expected a part of bufferList traversal.

That said, this is a good point. It made me realize it would be clearer to explicitly nullify the currentByteBuffer field in close(), just as we already call bufferList.clear(). I’ll update accordingly - thanks! Let me know what you think.

[nhachicha]

🎉