It will, definitely. I had two solutions ready in my mind (that rely on having more than one buffer active):
1. *Simplest, and fastest* but with *some drawbacks*: when buffer.isTooDefragmented() then simply buffer.clear() - you loose everything, but - hey, it's a cache, not a db 2. *Less simple, slower, less drawbacks*: when buffer.isTooDefragmented() mark the buffer as readOnly and then foreach (ptr in buffer) copy ptr.content in emptyBuffer and update ptr accordingly where *isTooFragmented==number_of_empty_pointers over total_pointers > desirable quota* The first one could be accomplished during a put() operation (buffer.clear is a logical operation that takes no time) while the second should be taken care of by the background thread. Those quick&dirty solutions could of course be replaced with real defragmentation algorithms - may taken from various malloc() implementations, that are the original inspiration http://en.wikipedia.org/wiki/Malloc#Implementations Beside that: I think this was filed in github issue tracker as an enhancement together with some more - I think I should re-file them in JIRA. Ciao, R On Sun, Oct 16, 2011 at 9:31 AM, Ashish <[email protected]> wrote: > Folks, > > Will the offHeapMemoryBuffer get fragmented over time? Say after a > couple thousand get/remove operations, will the off-heap have start > having holes in the Buffer? > > -- > thanks > ashish >
