On Tue, Jan 24, 2017 at 3:23 AM Dan Berindei <dan.berindei@gmail.com> wrote:
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,

The only issue I had with an argument name like initialCapacity is then I would assume the capacity (array) can grow, which it does not. Also the word just capacity makes me think I can't have more entries than that, which you can. Did you have any ideas on names or you really like initialCapacity?
 
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.

The problem with it being a proper entry is then the size is unknown, where as I know the size of all pointers. I can't really allocate a big block for the pointers then, and I wouldn't want to keep track of all of the pointers in Java since those would be on heap.
 
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@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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev