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

Ray Ingles reassigned GEODE-9499:
---------------------------------

    Assignee: Ray Ingles

> 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
>
> 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)

Reply via email to