[infinispan-dev] Eviction redesign

Hey, As a part of new eviction design for 4.1.0 we might require a slight DataContainer API change. Eviction in 4.1.0 will be piggybacked on user threads; current default option using a dedicated eviction thread from EvictionManager is maintained. Option to choose eviction approach will be configurable. If we are evicting on a dedicated thread (as we are in the current design) then we would have to rely on iteration of DataContainer entries to evict them (i.e that is the contract between EvictionManagerImpl and DataContainer). In order to support current design I'd have to implement iterator that returns evicted entries along with other non evicted entries. Iterator should put evicted elements prior to non-evicted elements (so EvictionManager would actually pick evicted entries for eviction). Continuing support of this contract feels like a kludge... A better solution seems to be adding a following method to DataContainer: Iterator<InternalCacheEntry> getEvictionCandidates() By default, we would return list of entries that were evicted and collected by attached listener to BoundedConcurrentHashMap. If eviction is done on user thread this iterator would be empty, just as it would be empty in case of UnboundedContainer. getEvictionCandidates method would be a new contract between EvictionManager and DataContainer. Method iterator() would therefore return actual non-evicted entries in eviction enabled BoundedContainer and all elements for UnboundedContainer. This approach keeps iterator() contract valid for all containers at the expense of breaking DataContainer API. Note that BoundedConcurrentHashMap is a lock amortized eviction enabled version of ConcurrentHashMap. BoundedDataContainer is a new container that will implement LRU and LIRS eviction algorithm. SimpleDataContainer will be renamed to UnboundedDataContainer. FIFO eviction will default to LRU. Other data containers (in current repository) will be deprecated/removed. If you have any comments/ objections speak up. Regards, Vladimir