[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?
>

Yes, I was hoping people would assume that from me saying it isn't
different.  But I can clearly state it.


> 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.
>

It is a bunch of longs that each point to an entry object off heap.  I
would love to have compressed oops, but we are kinda at the mercy of malloc
so there is no way to guarantee where the addresses will be allocated at.


> 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.
>

Sure can.  The way this works is pretty intrinsic to the current design,
since it utilizes these known facts to iterate over the entries with as
minimal locking as possible.


> 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).
>

I actually had it in here, but in my many edits it was lost.  I will add it
back in.  It is actually in the javadocs already however it was missed in
the schema, I will add it there.


> 5. Does bounded off-heap need extra locking?
>

It does I mention in the overhead it requires an additional lock.  I was
trying not to go into super details.


> 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.
>

I can clarify it obviously isn't an additional address pointer.  I was
trying not to be specific with the usage but rather give an approximation
of the overhead instead.

As you may have noticed I was torn with how specific to be. Originally I
had the document much more detailed about how things worked, but I tried to
pair it down. I was thinking maybe if we thought there was interest I could
go into more details in a future blog post.


>
> 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/e82dd1fd/attachment.html