Re: [infinispan-dev] Data Container Changes Part 1

I have some small comments on the blog post. I didn't read almost any of the code, so I guess I match the experience of a typical reader :) 1. Can you really use eviction="COUNT", like for the other memory types? 2. The address-count name is a bit odd, as it invites comparison with the native pointers: are our addresses ints on 32-bit and longs on 64-bit, do we have something similar to compressed oops etc. I'd rather call it initialCapacity, like the HashMap constructor argument, to allow us more wiggle-room in the implementation. E.g. we don't need the entry in the table to be just a "next" pointer, it could be a proper entry with a pointer to the key and maybe even a hash code. 3. The details on the way we do the locking and the actual number of ReadWriteLocks we use also sound like they could become out of date quickly. I'd put these and the memory overhead in a "Implementation Details" section. 4. Reading the code, it looks like address-count is also rounded up to the next power of 2, I think that should be mentioned here (and in the javadoc/schema). 5. Does bounded off-heap need extra locking? 6. 36 bytes for "an additional address pointer" seems a bit excessive :) Here too, I'd rather give an estimate of the overhead instead of trying to explain exactly what we're using those bytes for. Cheers Dan On Tue, Jan 24, 2017 at 12:21 AM, William Burns <mudokonman(a)gmail.com&gt; wrote: