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