[infinispan-dev] Faster LRU

[Vladimir Blagojevic]

On 11-07-05 4:58 PM, Dan Berindei wrote:
> +1 Vladimir, I had a similar idea to implement a BCHM segment entirely
> using a single LinkedHashMap - obviously that requires a lot more work
> to integrate with the existing BCHM then using a LHM inside the
> eviction policy, but it should also be more memory efficient.
Ok great! I still want to keep BCHM lock amortization unless someone can 
prove that they have a better solution.

> I would definitely remove the old LRU, it's much harder to understand
> because of the batching and the JDK already has tests to guarantee
> that LinkedHashMap is correct.
>
> One idea for testing I was discussing with Galder on my pull request's
> page was to simulate a real cache workload, with get misses triggering
> a put and also a small delay, in order to evaluate how good an
> eviction policy is at keeping the most used keys in.
>
> We definitely need to *some* testing for this, we can't afford to wait
> for another community member to come in a year's time and prove to us
> that we're rubbish :)
>
I think I've nailed it now as the results I am getting are correct in 
terms of segment sizing and everything else. Performance looks very good 
as well.

How about we do the following. I'll issue a pull request for an updated 
LRU along with my updated MapStressTest. I will use LRU name for this 
faster version, I'll rename current LRU as OLD_LRU and if all 
correctness, performance and other tests we have prove new LRU works as 
it should we'll just drop OLD_LRU from code altogether prior to 
5.0.Final. As soon as this pull is integrated you can add your eviction 
correctness code to MapStressTest or make a new test - whatever suits 
you better!

Any objections?

Regards,
Vladimir