[infinispan-dev] Data Container Changes Part 1

[William Burns]

On Tue, Jan 24, 2017 at 3:23 AM Dan Berindei <dan.berindei at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170124/45d3f834/attachment-0001.html