Reusable buffers as parameter for getters

[mufumbo]

Hi,

It would be great to be able to pass custom byte[] buffers as parameters for the GET and SET methods. Using the byte[], offset and size as parameters.

Basic use case for SET:

1. I have already a buffer that converts Java objects to Kryo serialized objects using a byte[] buffer. (instead of creating new byte[] every time and destroying the GC)
2. Then I use this buffer (with offsets) to compress it using Snappy (using offsets again, instead of generating new byte[] every time and destroying the GC again)
3. Then, NOW it would be amazing to use the buffer from 1) here and flush it using offsets back to the memcached socket.

Basic use case for GET:

1. I want to use my custom byte[] buffer to get the data from a memcached key
2. From that result (offset + len), I can then pass this same buffer to a Snappy.decompress method, using another cached buffer.
3. From this Snappy decompresse result, then I can use a Kryo.unserialize using the buffer from 1).

Again, the goal is to not create any objects through the usage of memcached. This random creation of byte[] kills the JVM GC, at least with G1 or concmarksweep. We had to migrate to shenoah for faster "Stop the World" GC, but still it would be wonderful to not create new byte[] for every single object inside memcached (we have millions).

I couldn't see how to do this with XMemcached and Spymemcached, any suggestion how to achieve this with Folsom would be greatly appreciated. I can send a PR if someone send me some pointers where to touch.

thanks!
rafa

[krka]

Reducing memory allocation footprint is always nice - we could do some basic investigation to see what we can get done.

Getting it down to no allocation per request seems unfeasible, and netty does some allocation of its own, as well as doing its own buffer management. Perhaps we can reuse some of that to minimize unnecessary copies.

Doing this, we also need to make sure we don't overly complect the API or introduce any new problems (memory leak but not releasing the objects or bugs by using the same objects for multiple concurrent requests). I would consider avoiding such bugs to be more important than performance gains.

We should also try to benchmark the performance difference of any such change. It may be possible that short-lived byte[] objects that doesn't escape the heap/lives on a single thread are already sufficiently optimized by the JIT.

If you want to make a PR, we'd be happy to review it as long as it's reasonably sized :)