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