about concurrentlinkedhashmap replacement polic

[you fu]

the doc:

• LRU page replacement policy (currently being upgraded to LIRS).
• Equivalent performance to ConcurrentHashMap under load.
• Can bound by the size of the values (e.g. Multimap cache).
• Can notify a listener when an entry is evicted.

the current version replacement policy is LIRS?

how to use guava LoadingCache with  LIRS replacement policy.

the guava default replacement policy is LRU.

LocalCache class :

The Least Recently Used page replacement algorithm was chosen due to its simplicity, high hit

   * rate, and ability to be implemented with O(1) time complexity. The initial LRU implementation

   * operates per-segment rather than globally for increased implementation simplicity. We expect

   * the cache hit rate to be similar to that of a global LRU algorithm.

[Ben Manes]

Hi,

I'm sorry that I wasn't available to answer your questions earlier. This may no longer be of interest to you, but I'll try to answer anyways.

the current version replacement policy is LIRS?

No. This has been on the backlog for a long time due to unsuccessful attempts. It was planned for the v2.0 release which is unlike to happen. The LIRS policy is complex, but can be implemented in a straightforward fashion in a single threaded context. The successful implementations I've seen required an exclusive lock around the LIRS and hash table to avoid race conditions. At best this can be segmented for concurrency, but while pragmatic it is a poor substitute in the long run.

As CLHM tries to maximize concurrency, my LIRS attempts have resulted in discovering and trying to work around race conditions. When I had most of these fixed, I still felt uncomfortable moving forward with the cache policy. If it is hard to reason about to write the code, it is even more difficult to codify that into test cases. Neither the authors of the LIRS papers nor subsequent open-source implementations contain any substantial tests. I concluded that adoption would require a more rigorous and longer path than I was willing to pursue at that time.

how to use guava LoadingCache with LIRS replacement policy.

Guava's Cache does not include a LIRS implementation. The lack of expertise with respect to concurrency and caching in general within the Guava team makes this very unlikely in the near future. There is an implementation with the Guava interfaces in Jackrabbit.

I saw that you posted a related question to the Guava mailing list with respect to the relationship of these two projects. Charles Fry and I ported code and tests from CLHM into Guava, and matured that into the present Guava Cache library. That implementation suffers from a very high degree of complexity, though. Unfortunately the Guava team had previously dedicated significant time implementing and promoting a soft reference based fork of CHM as the ideal solution to caching. While this is no longer recommended, we had to build off the existing code base which contained too few tests and mixed too many concerns. Charles did a great job so the cache today is robust and easy to use.

Sometime soon I plan on starting to work on a JDK8 rewrite of Guava's cache. That effort will include a cache tracing and simulator so that the decision to use an alternative policy is justified by evidence. If that project is successful then I will propose its adoption to the Guava core team and hopefully have a full implementation to contribute.

Best regards,

Ben

[you fu]

Thank you very much!