<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"></blockquote><div><br></div><div>Yes, I was hoping people would assume that from me saying it isn't different. But I can clearly state it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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">
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>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.</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"></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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"></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
5. Does bounded off-heap need extra locking?<br class="gmail_msg"></blockquote><div><br></div><div>It does I mention in the overhead it requires an additional lock. I was trying not to go into super details.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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"></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>