[
https://issues.apache.org/jira/browse/GEODE-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ray Ingles resolved GEODE-9499.
-------------------------------
Fix Version/s: 1.15.0
Resolution: Fixed
Implements static ThreadLocal storage for delta information in RedisData to
avoid an object reference per instance.
> RedisData does not need an object reference to implement Delta
> --------------------------------------------------------------
>
> Key: GEODE-9499
> URL: https://issues.apache.org/jira/browse/GEODE-9499
> Project: Geode
> Issue Type: Improvement
> Components: redis
> Reporter: Darrel Schneider
> Assignee: Ray Ingles
> Priority: Major
> Fix For: 1.15.0
>
>
> Currently every redis data structure implements the RedisData interface. Part
> of that implementation is Delta support. The way it is implemented is by
> storing a reference to a DeltaInfo instance in each RedisData. Most of the
> time this reference is null but it still takes up 8 bytes (4 if oops are
> compressed). It is only non-null while an update is in progress.
> What we could do instead is store the reference to the DeltaInfo in a thread
> local. That works because we are careful to run each redis command that
> modifies a RedisData on the primary. We lock the primary down during the
> operation to prevent it from moving. So when it comes time for the primary to
> call toDelta on the RedisData instance to distribute it to the secondary,
> this call will done on the same thread so our hasDelta and toDelta can just
> read the ThreadLocal. This will save us one object reference for every
> redis key we store.
> Something else we could consider doing is to pass the DeltaInfo as the
> callback arg when we do the region put. But this would require change to core
> geode to detect that the callback arg is a DeltaInfo and to use it to compute
> the delta bytes that are stored on the EntryEventImpl. This is doable and may
> even perform better but would require changes to the core. It would probably
> be a bit faster than the ThreadLocal solution just because of the extra
> latency in setting and reading a ThreadLocal compared to a stack parameter
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
