Should reseting a ByteBlockPool zero out the buffers?

[stefanvodita]

Description

ByteBlockPool.reset can fill the buffers we're recycling with zeros.

1. Do we need the buffers to be filled with zeros? Is there some implicit assumption if we were to reuse them that we would only encounter zeros?
2. If yes, should the responsibility move from ByteBlockPool to the Allocator's recycleByteBlocks method? The ByteBlockPool loses its reference to the buffers it's just zeroed, so it seems outside its concern to zero the buffers. The Allocator could zero the buffers in its recycle method if it needs to.

[stefanvodita]

I spent some more time with the code and I can attempt answering the questions in the description.

1. Yes. We rely on zeros in slice buffers to tell us where a slice ends (the first non-zero byte is the last byte of the slice) (example). There are two cases where we do this. The first is in TermsHashField (code) for a byte pool that is never reset. That means we don't have to zero out the buffers of a byte pool. The second is in MemoryIndex (code) for an int pool that is reset, so we can't skip zeroing out the buffers on reset.
2. Yes, I think it makes more sense for the Allocator to handle zeroing the buffers, but I don't think there's enough of a benefit to make the change on its own.

So, is there anything to be done? We can remove the option of zeroing byte buffers and move the responsibility for zeroing int buffers to the Allocator. Is that worth doing? Maybe, but it's not obvious to me that there is enough of a benefit to change how things already work.

[stefanvodita]

Both the follow-up PRs are merged. I don't think it's worth pursuing this further. Closing.