[jira] [Closed] (GEODE-9499) RedisData does not need an object reference to implement Delta

["Owen Nichols (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Owen Nichols closed GEODE-9499.
-------------------------------

> 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.20.7#820007)