On Tue, Jan 24, 2017 at 3:23 AM Dan Berindei <dan.berin...@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 <mudokon...@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 <mudokon...@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 >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev