[infinispan-dev] ISPN-863 proposal
Vladimir Blagojevic
vblagoje at redhat.com
Mon Jan 31 12:18:12 EST 2011
Yes you are accessing the lock-free queue but you are also locking a
segment repeatedly to remove each entry selected for eviction
(MemoryGuard#evict). While this might not be the end of the world it
will cause lock contention.
Regards,
Vladimir
On 11-01-31 12:37 PM, david marion wrote:
>
> As a user I'm not tied to any specific implementation (I just want
> the feature), but I 'll have to look at the code to fully understand
> your suggestion. I don't have the code in front of me at the moment
> (I'm at work). However, I don't believe I lock anything specifically.
> It's very possible that I am doing something that is causing lock
> contention, can you point me to where this is occurring? I am
> accessing the same per segment lock free queue that the article mentions.
>
> -- Dave Marion
>
> ------------------------------------------------------------------------
> Date: Mon, 31 Jan 2011 11:57:53 -0300
> From: vblagoje at redhat.com
> To: infinispan-dev at lists.jboss.org
> Subject: [infinispan-dev] ISPN-863 proposal
>
> Dave,
>
> I applaud you for this effort and your implementation and wiki are
> indeed admirable as you have followed the goals outlined in this JIRA.
> However, now that I have had an opportunity to look at the final
> solution I have one concern. We went through a great lengths to design
> a container that has a low lock contention [1] while maintaining high
> precision of a sophisticated eviction algorithm. Goals outlined in
> this JIRA have lead you in a direction to redesign the original
> proposal. I was wondering if it is possible to use your MemoryMonitor
> to make a decision whether or not to grow BCHM rather than to check if
> eviction should be done upon each put invocation? Currently we preset
> the size of BCHM and we never grow it (i.e. Segment#rehash is never
> invoked). Maybe this is a place where MemoryMonitor comes as a natural
> fit. We can keep the current design as outlined in [1] while reaping
> the benefits of a memory bound resizeable container.
>
>
> WDYT?
>
>
> Regards,
> Vladimir
>
>
>
> [1]
> http://infinispan.blogspot.com/2010/03/infinispan-eviction-batching-updates.html
>
>
> Dave said:
>
> It took me some time to figure out how to use Git and add some more
> tests. I have pushed my changes to a topic branch located at
> https://github.com/dlmarion/infinispan/tree/ISPN-863-master.
>
> Please let me know if you have any questions or concerns. I have put
> up some documentation at
> https://github.com/dlmarion/infinispan/wiki/ISPN-863-Implementation
>
> -- Dave Marion
> _______________________________________________ infinispan-dev mailing
> list infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110131/697be861/attachment.html
More information about the infinispan-dev
mailing list