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.

Fix JavaDoc links

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)

Clarify method JavaDoc to match class documentation

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)

Fix calculation of JCache's access expiration (fixes ben-manes#158)

If the entry had been eternal then, on access, the current time was
set to a duration with the unit of nanosecond instead of milliseconds.

The JCache expiration time sometimes assumed wall-clock behavior and
not nanoTime's. For writes there are still 3 magic values and those
will be removed in the v3 JCache rewrite (to use Caffeine's variable
expiration).

Improved the documentation for Expiry. Unfortunately it would probably
be best if the currentTime parameter was not provided. This was free
as already obtained from the ticker, but that defaults to nanoTime and
is not a wall-clock value. The main use cases for the parameter would be
to calculate against an external resource's timestamp, but that must be
done with a wall-clock resolution (System.currentTimeMillis). The focus
on implementation details and writing docs late meant this API gaffe
was overlooked, resulting in hinting towards an error prone usage.

Prepare for release