Eviction Improvements in Infinispan 7.2.0.Beta1
As many of you are most likely aware Infinispan provides a way to limit how many entries are stored in a single node’s memory at a given time. This is configurable via the eviction element in xml or EvictionConfiguraitonBuilder through the programmatic configuration.
In 7.2.0.Beta1 we have made some internal changes to our internal eviction support. This mostly entailed moving our implementation to the new ConcurrentHashMap that was updated for Java 8. This provides for a few new benefits and behaviors.
Long Size Support
Previously our eviction entry amount was limited to the maximum value of an int (2^31) and was always rounded up to the nearest power of 2 (ie. 100 would be changed to 128 which is 2^7).
With the new changes you can store up to a long worth of entries and it is not constrained to a power of 2. Unfortunately Beta1 does not contain the changes to allow for a long to be configured yet, but this should be fixed before 7.2.0.Final is done.
Memory wide eviction size
The old bounded map performed it’s eviction based on evicting elements stored in the same segment. This could cause the map to evict entries before it actually hit the maximum size. This is described in detail here.
The new ConcurrentHashMap for Java 8 automatically resizes its number of segments. As such the old method of eviction will not work. Instead we keep track of all entries in the entire map and only evict when we go over the max size. This prevents entries from being evicted that may not be the the least recent (previously in the case of when many elements in the same segment were added).
Better scalability
Since we utilize the new ConcurrentHashMap this automatically resizes the segments based on the amount of entries in the cache. Increasing the number of segments has some various benefits.
Less blocking
With more segments, that means there is more fine grained locking when updating an entry. The determination whether an entry needs evicting is done outside of any lock, further reducing contention.
Lower time complexity
Since there are more segments there should be fewer hash collisions, which should provide O(1) complexity much more frequently for accessing a given key.
Cheers,
Will
Get it, Use it, Ask us!
We’re hard at work on new features, improvements and fixes, so watch this space for more announcements!Please, download and test the latest release.
The source code is hosted on GitHub. If you need to report a bug or request a new feature, look for a similar one on our GitHub issues tracker. If you don’t find any, create a new issue.
If you have questions, are experiencing a bug or want advice on using Infinispan, you can use GitHub discussions. We will do our best to answer you as soon as we can.
The Infinispan community uses Zulip for real-time communications. Join us using either a web-browser or a dedicated application on the Infinispan chat.
Infinispan
Boosting the performace since 2009.
