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