interest in selective eviction?

[spi...@addthis.com]

Hi folks,

Is there any interest in providing support for selective key eviction? We've created a fork that provides a mediator interface that accepts a key and a value as input and returns either true or false. The mediator is allowed to perform any side-effects it wishes to perform on the key and/or value before returning the boolean result. The cache only evicts entries for which the mediator returns true. Our use case is for a concurrent map data structure with a performant eviction policy that also supports stateful persistence of entries that are evicted from the cache. The ConcurrentLinkedHashMap supports all those requirements out of the box except for the stateful persistence. With the selective key eviction patch the stateful persistence is not immediately provided but it allows for the implementation of such a policy. The burden is on the user of the library user to ensure that his or her implementation of the mediator interface has concurrency semantics that are safe for their application.

To play the role of devil's advocate there are a number of potential criticisms of adding this feature. (1) Criticism that it does too much. It allows the user to construct a poorly performing ConcurrentLinkedHashMap. If, for example, their implementation of the mediator interface always returns 'false' then the cache will continue to grow without bound. In addition the body of the mediator function is executed when the segment lock has been acquired. This behavior is critical for our use case of the mediator. But if the mediator function takes too long to execute this will affect the performance of the cache. (2) Criticism that it doesn't go far enough. The patch does not implement a full stateful persistent cache. By making the patch small it can in theory support a larger number of use cases. It doesn't provide an out-of-the-box solution to any specific problem. I'd rather not guess at the concurrency semantics of someone else's application which is why I am in favor of these changes.

We'd love to merge these changes back into the git head to share knowledge. If it's not a good fit for the project we're happy to maintain a fork but the downside is that upstream changes to the head will take longer to reach the fork. Apologies ahead of time this patch has been made against the 1.3.2 release of the code. If there is interest in merging these changes I can volunteer for the effort to make the patch compatible with the git head.

Cheers,

--Michael

[Ben Manes]

Hi Michael,

I'm sorry for being MIA and I'm glad that you were able to add the features you needed to your own fork.

I find this change unsettling yet difficult to argue against. The criticism you cited are the same that I would have. I find calling foreign code under a lock to be very hazardous. I'd even say your (2) argument of not going too far doesn't go to far itself! Instead it could be argued that this is a custom eviction policy, so ideally that would be pluggable to allow greater control. Of course that's not possible due to the wide variety and complexities of different types of policies. Your mediator strikes a nice balance, yet with a single use-case and its potential for harm its an uneasy change.

At the moment I'd be inclined to recommend leaving it as a fork, since you've handled that successfully. I'd be open to debate the idea more, though.

That said, I do hope to start working on JDK8 rewrite of Guava's cache soon. This feature wouldn't be included in a more general purpose library as it is too error prone. Its fair to say that CLHM can put more trust on its users who want more low-level control. I would argue that I expected them to fork it and embed, like you did, because every special case is different. So the more torn I am about this proposal the less I can justify adding it.

Best regards,

Ben

P.S. I enjoyed your blog post =)