Updates #1
Open
Updates #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ben-manes
force-pushed
the
master
branch
2 times, most recently
from
940dca6 to
2f271e9
Compare
ben-manes
force-pushed
the
master
branch
2 times, most recently
from
ac8e049 to
08b24cd
Compare
ben-manes
force-pushed
the
master
branch
17 times, most recently
from
a337c19 to
48d5246
Compare
ben-manes
force-pushed
the
master
branch
2 times, most recently
from
53f222c to
00b1503
Compare
ben-manes
force-pushed
the
master
branch
2 times, most recently
from
73f40d3 to
6abd616
Compare
ben-manes
force-pushed
the
master
branch
2 times, most recently
from
a7d31f5 to
d74756d
Compare
Removed the usage from a unit test that requires a predictable ThreadLocalRandom result. This now uses reflection and the runner must explicitly open the module for access. Removed from a benchmark comparing table lookup mechanisms and the cache currently uses the VarHandles approach, Removed JDK 7's ConcurrentHashMap as this was only useful for judging the performance benefit of the Java 8 rewrite when trying to set baseline expectations during the library's initial development.
The relevant tests were extracted with minimal modifications to allow for them to be run on Java 11, by a non-main test harness, to add and only run the Caffeine implementations, and to fix issues with stateful statics that are modified within the tests.
The previous commit delegated an unbounded cache's toArray to the underlying map. This works for keys and values, but an entry may be modified. This wrote through to the map but bypassed being intercepted for the removal listener. Additional unit tests now assert this to avoid regressions, as the optimization seemed oddly missing and that nagging feeling was a reminder of why.
A test run failed thanks to using a random seed for the starting time, where overflow occurs if slightly more than 60s from the maximum. The expiration tests are now run to include a known bad seed to verify the calculation and their advancements set to trigger the scenario.
A zero or negative duration returned from the user's Expiry is treated as an immediate expiration. A negative value was being hashed into a future slot in the second wheel, so it delayed the eviction until that bucket is flushed. This now forces the entry to the current time's bucket so that it gets handled immediately after being added. I suspect that if a Long.MIN_VALUE was used that there might have been an overflow. I didn't investigate that scenario or its impact, as users can just return zero or a reasonably negative duration instead if oddly intentional. The primary cause for a negative if a mistakenly ordered Duration.between(t1, t2) call, so handling -292 years is a worthy test case but bad user code entries are unintentionally, immediatly discarded.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.