Switch from concurrentlinkedhashmap-lru to caffeine

[hakanai]

I noticed we have a copy of concurrentlinkedhashmap-lru in our project, pulled in by orient-core:

com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.4.1
\--- com.orientechnologies:orientdb-core:2.2.8

The project site itself says that Caffeine is the successor library and a ticket I just raised with concurrentlinkedhashmap got a reply saying that switching is recommended.

I would also prefer not to have more than one library for the exact same purpose in our project when possible, and in this case, since it seems to be a direct successor, it seems like it should be possible.

Would it be possible for orientdb to switch caching libraries to caffeine?

[lvca]

Makes sense for OrientDB 3 that will require Java8, but now we can't substitute it because OrientDB 2.2.x is Java7 compatible.

[andrii0lomakin]

@trejkaz @lvca why not will do

[taburet]

Most of our usages of ConcurrentLinkedHashMap are more like of a concurrent pool-like acquire/release pattern: (1) no size limit to avoid automatic eviction of acquired entries to let all pool clients share the same entry instance, (2) manual, sometimes batched, eviction management, (3) usage of ConcurrentMap#remove to handle the concurrent entry loading/unloading, (4) entries in some pools are relatively cheap to construct, so the pool/map/cache acts more like an interning instance-sharing pool.

Unfortunately, Caffeine has about x5 overhead on such usage pattern comparing to ConcurrentLinkedHashMap. Some of our pools are on really hot paths, for example OOneEntryPerKeyLockManager, which is used by OAtomicOperationsManager, which is touched by almost any database operation.

At this moment, I don't see real benefits in switching from ConcurrentLinkedHashMap to Caffeine on our pools. What we really need here is a flexible performant concurrent pool implementation, not a cache. Maybe one day we will do a second try on Caffeine and pools, if it receives a feature like this.

[ben-manes]

Perhaps stormpot is a better fit. It's an object pool that utilizes thread locals to improve acquisition time, with a concurrent queue for management.

If you have a benchmark (e.g. jmh) then I can investigate the slowdown.

[taburet]

Thanks for Stormpot, seems like that is a great thing. But it doesn't have mapping/interning semantics and seems like there is no cheap and easy way of introducing it. It will be a great fit for pure pools maybe with some kind of instance attach-detach semantics on top of it.

Regarding JMH benchmark, I will create one on spare time and let you know.