[infinispan-dev] Data Container Changes Part 1

[Dan Berindei]

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 at gmail.com> wrote:
> I just wanted to let you all know that Part 2 of Data Container changes is
> now ready.  Go ahead and check it at out at our new feature that we are very
> excited about at [2] !
>
> [2] http://blog.infinispan.org/2017/01/data-container-changes-part-2.html
>
> On Mon, Dec 19, 2016 at 4:10 PM William Burns <mudokonman at gmail.com> wrote:
>>
>> Check out some of the new changes to the Data Container in Infinispan 9.0.
>> Beta 1 [1].  Part 2 will be probably after Holiday break.
>>
>> [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev