<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 24, 2017 at 3:23 AM Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have some small comments on the blog post. I didn't read almost any<br class="gmail_msg">
of the code, so I guess I match the experience of a typical reader :)<br class="gmail_msg">
<br class="gmail_msg">
1. Can you really use eviction="COUNT", like for the other memory types?<br class="gmail_msg">
2. The address-count name is a bit odd, as it invites comparison with<br class="gmail_msg">
the native pointers: are our addresses ints on 32-bit and longs on<br class="gmail_msg">
64-bit, do we have something similar to compressed oops etc. I'd<br class="gmail_msg">
rather call it initialCapacity, like the HashMap constructor argument,<br class="gmail_msg"></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
to allow us more wiggle-room in the implementation. E.g. we don't need<br class="gmail_msg">
the entry in the table to be just a "next" pointer, it could be a<br class="gmail_msg">
proper entry with a pointer to the key and maybe even a hash code.<br class="gmail_msg"></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. The details on the way we do the locking and the actual number of<br class="gmail_msg">
ReadWriteLocks we use also sound like they could become out of date<br class="gmail_msg">
quickly. I'd put these and the memory overhead in a "Implementation<br class="gmail_msg">
Details" section.<br class="gmail_msg">
4. Reading the code, it looks like address-count is also rounded up to<br class="gmail_msg">
the next power of 2, I think that should be mentioned here (and in the<br class="gmail_msg">
javadoc/schema).<br class="gmail_msg">
5. Does bounded off-heap need extra locking?<br class="gmail_msg">
6. 36 bytes for "an additional address pointer" seems a bit excessive<br class="gmail_msg">
:) Here too, I'd rather give an estimate of the overhead instead of<br class="gmail_msg">
trying to explain exactly what we're using those bytes for.<br class="gmail_msg">
<br class="gmail_msg">
Cheers<br class="gmail_msg">
Dan<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On Tue, Jan 24, 2017 at 12:21 AM, William Burns <<a href="mailto:mudokonman@gmail.com" class="gmail_msg" target="_blank">mudokonman@gmail.com</a>> wrote:<br class="gmail_msg">
> I just wanted to let you all know that Part 2 of Data Container changes is<br class="gmail_msg">
> now ready. Go ahead and check it at out at our new feature that we are very<br class="gmail_msg">
> excited about at [2] !<br class="gmail_msg">
><br class="gmail_msg">
> [2] <a href="http://blog.infinispan.org/2017/01/data-container-changes-part-2.html" rel="noreferrer" class="gmail_msg" target="_blank">http://blog.infinispan.org/2017/01/data-container-changes-part-2.html</a><br class="gmail_msg">
><br class="gmail_msg">
> On Mon, Dec 19, 2016 at 4:10 PM William Burns <<a href="mailto:mudokonman@gmail.com" class="gmail_msg" target="_blank">mudokonman@gmail.com</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Check out some of the new changes to the Data Container in Infinispan 9.0.<br class="gmail_msg">
>> Beta 1 [1]. Part 2 will be probably after Holiday break.<br class="gmail_msg">
>><br class="gmail_msg">
>> [1] <a href="http://blog.infinispan.org/2016/12/data-container-changes-part-1.html" rel="noreferrer" class="gmail_msg" target="_blank">http://blog.infinispan.org/2016/12/data-container-changes-part-1.html</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> infinispan-dev mailing list<br class="gmail_msg">
> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
</blockquote></div></div>