[infinispan-dev] Eviction in Infinispan
Manik Surtani
manik at jboss.org
Mon Mar 23 16:18:52 EDT 2009
Hello all.
So as you know eviction changed pretty substantially from JBC3 but the
overall design still remained the same. I'm proposing a radical
change to the design, which we briefly discussed in Neuchatel.
Here's a recap of what has changed already since JBC3:
1. ExpirationAlgorithm and ElementSizeAlgorithm dropped,
unnecessary. Leaves us with {FIFO, LRU, MRU, LFU}
2. Eviction queue design improved to O(1) for most operations on most
algorithms, except LFU (O(log n))
3. Expiration treated as a top-level construct where lifespans for
entries can be provided on a per-entry basis
4. Eviction watermarks are now exclusively size-based (numElements)
and not time-based.
5. MinTTL still supported.
Now here is how I want to change things further:
1. Drop MRU and LFU. I don't see MRU being useful except in very
specific edge cases. LRU somewhat useful but very expensive.
2. Re-introduce a time-based watermark. Brian, this is where your
thoughts are most useful - how do you see this being used? In
passivation?
3. Get rid of the eviction queues. Unnecessary duplication of keys.
The core datastructure can be refactoreed to provide an efficient,
threadsafe lookup for entries, where entries are also ordered for
eviction.
4. To support 3. and make it as efficient as possible, eviction may
only be an approximation. (e.g., if items 1 - 10 are added in order,
and 3 need to be removed based on FIFO, we may lose 7, 9 and 10
instead of 8, 9 and 10.). How much of a concern is this? (typical
tradeoff of accuracy vs efficiency)
Cheers
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090323/51541cea/attachment-0001.html
More information about the infinispan-dev
mailing list