Clojure JIRA

[CCACHE-30] make-reference need not be dynamic

Sat, 9 Feb 2013 06:26:33 -0600

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?

[CCACHE-29] Is IPersistentCollection definition of cons correct?

Sun, 18 Nov 2012 15:44:43 -0600

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.

[CCACHE-28] SoftCache NullPointerException in has? with many threads

Sat, 9 Feb 2013 06:27:03 -0600

"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?

[CCACHE-27] Missing LU and LRU is linear complexity - performance

Wed, 12 Sep 2012 09:27:56 -0500

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?

[CCACHE-26] hit function in LRU cache can give funny results

Wed, 22 Aug 2012 21:06:13 -0500

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}

[CCACHE-25] TTLCache appears to have inconsistent behavior with respect to the TTL parameter

Tue, 14 Aug 2012 20:33:04 -0500

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).

[CCACHE-24] Numerous Reflective Calls in core.cache

Tue, 14 Aug 2012 20:33:34 -0500

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.

[CCACHE-23] Overwriting entries in LRU-cache deletes LRU key-values unnecessarily

Wed, 22 Aug 2012 19:28:53 -0500

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}

[CCACHE-22] Change limit parameter name in TTLCache

Fri, 15 Jun 2012 13:49:12 -0500

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

[CCACHE-21] LRU and LU caches never evict entries that came in as a seed and are never accessed

Wed, 14 Mar 2012 08:15:59 -0500

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.

[CCACHE-20] Add some examples to github page

Sun, 19 Feb 2012 18:24:14 -0600

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

[CCACHE-19] Create 3-arg version of lookup

Thu, 5 Jan 2012 07:36:38 -0600

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.

[CCACHE-18] Explore JSR 107- Java Temporary Caching API

Mon, 19 Dec 2011 07:23:32 -0600

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

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

[CCACHE-17] Create function backed cache

Mon, 19 Dec 2011 07:29:30 -0600

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.

[CCACHE-16] Benchmark v0.5.x against Google Guava

Fri, 16 Dec 2011 08:55:39 -0600

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

[CCACHE-15] It appears that TTL cache exhibits quadratic performance (+ its evict is buggy)

Thu, 15 Dec 2011 12:21:46 -0600

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...

[CCACHE-14] Asynchronous Cache Support

Tue, 13 Dec 2011 16:33:21 -0600

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.

[CCACHE-13] Deprecate Clache

Tue, 14 Aug 2012 20:34:42 -0500

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.

[CCACHE-12] LRUCache miss explodes if given an empty lru table

Fri, 9 Dec 2011 09:42:11 -0600

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.

[CCACHE-11] Add eviction implementation to LIRSCache

Thu, 8 Dec 2011 14:38:50 -0600

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.

[CCACHE-10] Add eviction implementation to LUCache

Mon, 12 Dec 2011 07:54:29 -0600

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.

[CCACHE-9] Add eviction implementation to TTLCache

Sat, 10 Dec 2011 07:35:22 -0600

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.

[CCACHE-8] Add eviction implementation to LRUCache

Fri, 9 Dec 2011 21:11:23 -0600

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.

[CCACHE-7] Add eviction implementation to FIFOCache

Fri, 9 Dec 2011 08:52:30 -0600

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.

[CCACHE-6] Cut 0.5.0 release jar

Tue, 13 Dec 2011 12:02:42 -0600

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

[CCACHE-5] Implement SoftCache

Fri, 13 Jul 2012 10:47:16 -0500

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

[CCACHE-4] Added LIRS factory fn

Thu, 8 Dec 2011 12:11:00 -0600

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

[CCACHE-3] Add LIRS support.

Tue, 6 Dec 2011 08:40:23 -0600

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.

[CCACHE-2] FIFOCache seed does not properly seed the FIFO queue

Fri, 9 Dec 2011 06:46:42 -0600

(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.

[CCACHE-1] Storing falsey value in underlying struct causes failure in get with not-found arg

Wed, 30 Nov 2011 10:57:33 -0600

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.