Chore: Extracted interface Cache from 'LRUCache' #130964
Open
+2,032
−1,526
Conversation
This file contains hidden or 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
…nder the old name to allow other implementations to be tested. - Found and fixed minor bug where we tested max weight against count() instead of weight - Found and fixed minor issue with possible long overflow. - Adjusted tests but made explicit the ones who rely on the `LRUCache` implementation to test if settings are applied correctly. While CacheBuilder#build() returns a `Cache` it still always returns the `LRUCache` implementation
elasticsearchmachine
added
v9.2.0
external-contributor
Updated Javadoc to clarify method behaviors, guarantees, and expectations for implementers of the Cache interface. Introduced default `refresh` method and improved descriptions for traversal methods, weights, and removal notifications for consistency.
…f preventing, very unlikely, overflow
- Refactored CacheTests to LRUCacheTests - Added new CacheTests that test for Cache contract - Added toString() to RemovalNotification
elasticsearchmachine
added
the
needs:triage
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.
Chore: Extracting a Cache interface to allow exploring alternative implementations. Alternative implementations are outside the scope of this PR.
I know indirection is bad for performance, but the
Cache/LRUCachealready lists trade-offs, I expect things to get inlined, everything considered I don't think this will 'do us in'.Along the way found some minor bugs and issues
LRUCacheimplementation to test if settings are applied correctly. While CacheBuilder#build() returns aCacheit still always returns theLRUCacheimplementationCache.CacheStatstoCache.Statsand made it a record. Getters we're kept for now, should perhaps inline access in the future.RemovalListenerand how the interface doesn't mandate how, how many and effects if registered listeners are modified after constructionNOTES (ramblings of the author, for context, can be ignored):
The wording of javadoc of the old
Cache/LRUCachemight have sounded 'overly scary/dangerous' leading to some interesting usage/interactionAs already pointed out in comments org.elasticsearch.xpack.core.security.support.CacheIteratorHelper, it's a little wonk. I'm also unsure if the extra protection is needed. Regardless the design of that class to leak the locks and not pull up interaction and fully decorate a cache a la Collections.unmodifiableXXX(XXX) is... 'not (personally) preferred'.
A computed weight is being tracked as long, which can overflow. Always calculating it on the fly or calculating it on the fly after detecting overflow is an option. Also wondering about thread safety as we're incrementing and something like an AtomicLong is needed. 'Best-effort' :-) Changing the LRUCache impl is out of scope of this PR.
TODO / Ponder on
We both have a forEach() to loop all entries and two iterators to loop over keys and values separately - should probably harmonize this using the same pattern for all 3?not changing LRUCachethe forEach locks the segment, iterators do not, neither provides a point-in-time view of the cache, not sure what the benefit of the guarantee of locking the segment does to the consumer, since which entry belongs to which segment is an internal detail so interaction has no guarantee of hitting any particular segment. If one safely (correctly?) assumes the lowest common denominator it would provide the same guarantee, with the other just having the downside of potentially deadlocking.not changing LRUCacheweight() perhaps move it to stats?weight doesn't have a fixed unit.