If one initializes an LRU or LU cache with seed data and those datum are never touched, then they are never evicted.

  (def C (lru-cache-factory {:a 1, :b 2} :limit 2))
  
  (-> C (assoc :c 3) (assoc :d 4) (assoc :e 5))

You would expect that the cache should contain only :d and :e, but it instead includes :a, :b, :d and :e! The problem is that seeds are never added to the eviction queue.

Cache c seeded with {:a nil} and accessed via (get c :a 42) returns 42 instead of nil. The reason for this is that the map vatAt delegates directly to the lookup protocol function without a has? guard.

Clache had an implementation of the LIRS http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.116.2184 strategy. This capability should be merged into core.cache also.

LIRS is implemented as a type only ATM. There should also be a corresponding factory fn.

(def c (clojure.core.cache/seed (FIFOCache. {} nil 1) {:a 1 :b 2}))

(defmethod print-method clojure.lang.PersistentQueue [q, w]
  (print-method '<- w)
  (print-method (seq q) w)
  (print-method '-< w))

(str c )
;=> "{:a 1, :b 2}, <-(:clojure.core.cache/free)-<"

(str (assoc c :c 3))
;=> "{:a 1, :c 3, :b 2}, <-(:c)-<"

The queue never gets the seed keys :a and :b and so they will never get expelled.

The evict method in the ProtocolCache needs implementation for FIFOCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc which in turn forms the basis for proper limited seeding. Currently only the BasicCache impl has evict.

The min-key method used to determine least tick explodes with:

clojure.lang.ArityException: Wrong number of args (1) passed to: core$min-key

This is a corner case that should be handled.

The evict method in the ProtocolCache needs implementation for LRUCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc which in turn forms the basis for proper limited seeding. Currently only the BasicCache impl has evict.

The evict method in the ProtocolCache needs implementation for TTLCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc. Currently only the BasicCache impl has evict.

The evict method in the ProtocolCache needs implementation for LUCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc which in turn forms the basis for proper limited seeding. Currently only the BasicCache impl has evict.

The core.cache functionality, with LIRS will be inline with Clache. A release should be cut and pushed to Maven central pending CCACHE-4.

Currently, lookup comes in only the 2-arg flavor (i.e. gimme a key and I'll give you a value or nil). The issue with this is that nil is potentially a legal value. Therefore, the 3-arg version logic is the same as the 3-arg `assoc` (.lookup this key not-found).

This change should propagate to all of the existing cache impls.

Clache had a buggy implementation of a cache backed by soft references. This capability should be explored further and implemented properly for core.cache.

To "overwrite" the value in an LRUCache, one uses assoc. Surprisingly, another k,v entry is evicted, even though the total number of items in the cache should not be increased by overwriting.

Demo:

(def C0 (lru-cache-factory {} :threshold 3))
; --> #<Var@7ec74910: {}>

(def C1 (-> C0 (assoc :a 1) (assoc :b 2) (assoc :c 3)))
; --> #<Var@315863e4: {:c 3, :b 2, :a 1}>

(-> C1 (assoc :a 4) (assoc :a 5) (assoc :a 6))
; --> {:a 6}

When I run lein check on my code, core.cache is a source of many reflective calls. Fortunately they don't seem to account for much time in my own profiling. But given that the purpose of a cache is to provide access to time-critical things, and the library can't easily anticipate the usage patterns of its users, it would be nice if we could remove these reflective calls, particularly where there does not appear to be any restriction to the use of the cache by doing so (that is, most of these appear to be from Java interop calls that are entirely inside the implementation of the caches).

Here's the output from lein check listing the reflective call sites:

Reflection warning, clojure/core/cache.clj:87 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:87 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:107 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:107 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:149 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:149 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:187 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:187 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:241 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:241 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:273 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:273 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:398 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:398 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:471 - reference to field poll can't be resolved.
Reflection warning, clojure/core/cache.clj:473 - call to remove can't be resolved.
Reflection warning, clojure/core/cache.clj:474 - call to remove can't be resolved.
Reflection warning, clojure/core/cache.clj:475 - reference to field poll can't be resolved.
Reflection warning, clojure/core/cache.clj:482 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:482 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:486 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:488 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:491 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:500 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:507 - call to put can't be resolved.
Reflection warning, clojure/core/cache.clj:508 - call to put can't be resolved.
Reflection warning, clojure/core/cache.clj:515 - call to remove can't be resolved.
Reflection warning, clojure/core/cache.clj:516 - call to remove can't be resolved.
Reflection warning, clojure/core/cache.clj:528 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:528 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:562 - reference to field q can't be resolved.

There appears to be some inconsistency in the implementation of TTLCache. Specifically, it appears that if you lookup a value whose TTL has expired, but no new items have been added to the cache, it will still be present. But if you ask if the cache has? the value, it will report that it does not. For example:

```
user> (defn sleepy [e t] (Thread/sleep t) e)
#'user/sleepy
user> (-> (ttl-cache-factory {} :ttl 1000) (assoc :a 1)
(assoc :b 2)
(sleepy 2200)
(has? :a))
false
user> (-> (ttl-cache-factory {} :ttl 1000) (assoc :a 1)
(assoc :b 2)
(sleepy 2200)
(get :a))
1
```

So here we see, has? reports the value is no longer in the cache, but get will still give you the value. Unless I am misunderstanding the purpose or contract of these two functions, it seems that they should agree in whether or not a value is in the cache.

This also brings up the question of whether a value in a TTL cache that has passed the TTL should remain in the cache until the cache is updated. My expectation was that an item is not in the cache after the TTL has passed (ie, has? is currently correct). I can also see the argument that the TTL parameter is merely a lower bound on the amount of time it is cached; if it can be accommodated for longer, it will be (and thus lookup is currently correct).

As I said, my expectation was that things are no longer in the cache after the TTL, and I would still vote for this behavior as the correct one for a TTL cache, as it seems like a reasonable cache to use for things that can change out from under you, but a short period where it is out of date is acceptable (which is how I was trying to use it).

core.cache was originally Clache , but its inclusion into contrib means the latter is redundant. The Clache repo should indicate the move and change to a place for docs and examples. Likewise, a formal announcement should be made.

"limit" is used in other caches to represent quantity, for TTL it represents time. Using the same name is confusing

A common-sense usage in caches is hit/get. But if I naively do this to an LRUCache, without checking first for the presence of the key, I can break the limit.

(-> (cache/lru-cache-factory {} :threshold 2)
(cache/hit :x)
(cache/hit :y)
(cache/hit :z)
(assoc :a 1)
(assoc :b 2)
(assoc :c 3)
(assoc :d 4)
(assoc :e 5))

; {:e 5, :d 4, :c 3, :b 2, :a 1}

The evict method in the ProtocolCache needs implementation for LIRSCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc which in turn forms the basis for proper limited seeding. LIRS poses an additional complication due to its dual limit lists. Currently only the BasicCache impl has evict.

Perform some tests and benchmarks of core.cache and Google Guava's com.google.common.cache library.

A cache implementation that is backed by a function that performs some action on a cache miss could serve as a front for any of the existing cache impls.

The library looks useful, thanks!

I looked at the code, and unless I'm mistaken, every cache miss seems to result in a full pass over the entire cache to evict old entries. The performance implications of this would be unacceptable for my target application. Replacing the TTL data structure with a persistent analog of a LinkedHashMap and using a take-while instead could fix this problem.

Also, evict seems to pass the cache in twice, rather than the cache and the TTL...

Could you add some examples on how to use core.cache to github readme?

Profiling some code with YourKit showed a hotspot in cache statistics on (miss) for LU and LRU caches.

Basically two issues: (count (keys {....})) is a count of a seq, not efficient. Replaced with a count of the map.

Secondly, (apply f anything) is slow. Profiler showed that the (apply min-key) was really slow. This is mitigated by using a c.d.priority-map instead. On a priority-map, (ffirst {}) or (first (peek {}).

Also inverted the logic for threshold comparison. Since there is a (build-leastness-queue) that populates statistics, should caches should favor codepaths for the state of being full all the time?

Here's the definition of `cons` for caches:

clojure.lang.IPersistentCollection
(cons _# elem#
(clojure.core/cons ~base-field elem#))

This seems wrong to me. Note first that the arguments to `clojure.core/cons` are in the wrong order. As a result, the result of (for example) conj is incorrect. Consider this:

user=> (def starts-with-a (cache/fifo-cache-factory {:a 1} :threshold 3))

#'user/starts-with-a
user=> starts-with-a
{:a 1}
user=> (conj starts-with-a [:c 3])
({:a 1} :c 3)

Even if the argument order was correct, the result would still be a sequence rather than the type of the base field. I think you want something more like

clojure.lang.IPersistentCollection
(cons this# elem#
(apply assoc this# elem#))

After all, this particular collection is an IPersistentMap, so its `conj` and `into` behavior should be the same as other objects for which `map?` is true.

It looks like make-reference was made dynamic to support multiple clojure versions. Rebinding make-reference is really only needed for tests, and it would be a shame if making it dynamic causes performance issues.

Perhaps it is not enough of a performance issue to worry about. Otherwise, it might be possible to work around it. Perhaps directly pasting in and using the with-redefs macro, or something similar?

"cell" can be null on this call to SoftReference.get():
https://github.com/clojure/core.cache/blob/master/src/main/clojure/clojure/core/cache.clj#L501

If the cache did not contain "item" in the call to (get cache item) in the let binding, but another thread pre-empts and adds it before the subsequent call to contains?, we'll attempt to call .get() on nil.

Would it perhaps be sufficient to just check whether cell is nil instead of calling contains? in the check on the previous line?

If people start implementing the cache protocol on top of external caches: Memcache, Redis, or others, an async version could make sense.

I started toying with an AsyncCacheProtocol which for all functions returning values would take two arities, a standard one which would return an instance of IRef, a second one which would take an extra callback argument to be called with the results. This doesn't solve everything though and async versions of LRU and friends would have to be implemented.

The alternative would be to have additional calls in CacheProtocol, such as async-has? async-lookup which would implement the 2 arity semantics and then rely on the fact that the underlying cache respects some sort of async semantics, since we cannot do that with Associative, maybe another middleman protocol CacheStorage could be used, this way, all external cache providers would have to do is implement a CacheProvider with optional asynchronous support.

I hope at least part of this makes sense.

Is this relevant to core.cache? And many other questions answered.

<http://jcp.org/en/jsr/detail?id=107>