Tags: gitandroidhui/caffeine
Tags
Replace multiplication with shift Since the multiplier is a power-of-two, we should avoid relying on the compiler noticing that and perform the optimization directly. Of course, the JIT does realize this in C2, but ideally we don't write code making those assumptions as easy to regress.
Fix variable expiration overflowing with the maximum duration (fixes b… …en-manes#217) When the duration is set to the maximum length, Long.MAX_VALUE nanoseconds, the calcuation of expirationTime - currentTime > 0 may overflow and be negative. This will not occur if the same thread calculates both timestamps. It may occur across threads when the expirationTime is concurrently updated using a later base time than t1's reading of the currentTime. This can occur whenever the maintenance work is triggered to sweep expired entries and a user thread accesses the entry. The later timestamp plus the maximum duration results in an overflow, causing the remaining time to be negative, and therefore causes the cache to expire the entry. The internal maximum is now capped at Long.MAX_VALUE / 2 or ~150 years. This should give a broad safety net to avoid these concurrency-inducing overflows in normal code.
Fixes for the JCache 1.1 preview, except for 1.0 TCK breaking changes A preview of JCache 1.1 has been made available for review until 11/18. This update includes JavaDoc fixes, spec corrections, additional tests, and fixes incorrect tests. The 1.1 TCK is not compatible with 1.0's TCK. Some tests assert the opposite behavior, such as relaxing types to not throw exceptions or changing the statistics of putIfAbsent. Since 1.1 is in preview, we maintain 1.0 compatibility with the acceptable fixes uncovered by the later TCK. In particular the specification requires that a loader, writer, expiry, and listeners are closed if they implement Closable. This was in the JavaDoc but not the TCK, making it easy to overlook. https://jcp.org/aboutJava/communityprocess/maintenance/jsr107/107MR1-summary.html
Disable statistics for TCache in JMH benchmarks (ben-manes#185)
Don't refresh automatically when waiting for a slow reload (fixed ben… …-manes#175) If the load time exceeded the refreshAfterWrite time then a new refresh is triggered and the previous was ignored. This was due to how the write timestamp is used, which was set to the current time to delay expiration and refresh. When the refresh completes it CAS's to the new value only if no other writes occurred (so as to not stomp explicit writes and reload a stale read). The slow reload meant that only the last refresh would be honored, which may not occur for a long time on a busy system. This also removes a sync vs async difference that I never remembered why it was in place. Async didn't have this problem due to the timestamp being pushed out into the distant future. Since I didn't recall why these were special cased I had kept them as is, hoping the previous me was smarter than the current. Seems both were pretty dumb.
Fix TravisCI build Due to exceeding the 50 minute time limit, the support team was very kind by extending it to 90 minutes. For now, merging this slow tests into the same job for a fuller code coverage report. Moving to a VM instance (vs container) for a beefer machine. This had hung because some Guava tests block indefinitely on CountDownLatches. Since I had switched their tests to use a pool instead of new threads, thread starvation meant no progress could be made. Reverted to ad hoc threads and added a timeout to the awaits().
Fix variable expiration with async cache (fixes ben-manes#159) An in-flight future was mistakenly given the maximum expiry allowed, causing it to not honor an expire-after-create setting. Instead it was supposed to be beyond the maximum to signal adaption on the completion update. The calculations for fixed expiration was made more robust to the time rolling over. This now complies with System.nanoTime() warnings. Strengthened the remove and replace operations to be more predictably linearizable. This removed optimizations to avoid unnecessary work by checking if the entry was present in a lock-free manner. Since the hash table supresses loads until complete, that might mean that a call to remove a loading entry was not performed. The contract allows either, so the optimization is left to user code and gives preference to those who need the linearizable behavior. (See ben-manes#156)
PreviousNext