[
https://issues.apache.org/jira/browse/GEODE-9772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9772:
------------------------------------
Affects Version/s: 1.15.0
> RedisString should consistently use a DeltaInfo for all write ops that update
> a RedisString
> -------------------------------------------------------------------------------------------
>
> Key: GEODE-9772
> URL: https://issues.apache.org/jira/browse/GEODE-9772
> Project: Geode
> Issue Type: Improvement
> Components: redis
> Affects Versions: 1.15.0
> Reporter: Darrel Schneider
> Priority: Major
>
> Currently RedisString generates a DeltaInfo instance when it does an "append"
> to an existing RedisString. But for all the other write ops on RedisString
> the implementation does not generate a DeltaInfo instance. This causes the
> entire RedisString instance to be serialized to the secondary. But the ops
> that do this tend to change the entire string (for example "set" get rid of
> the old value of the string and adds a brand new value). But even for these
> types of ops being consistent about generating a DeltaInfo has the following
> benefits:
> 1. the memory usage on the region will be consistent between the primary and
> secondary because the value will be stored in the same form on both of them.
> Understand that for value classes that implement the Delta interface (which
> all RedisData classes do) the primary will always store the value in
> deserialized form. But it gets stored on the secondary in serialized from
> until a value arrives on the secondary that is just the delta bytes. By
> generating a DeltaInfo instance the secondary will receive data bytes.
> 2. By keeping the values stored in the region in object form it causes
> updates to not produce "old garbage". What happens when a DeltaInfo is sent
> is that it modifies in place an object that is already in the JVM heap
> memory. But without a DeltaInfo a whole new value is created and the old
> value becomes garbage. That old value may have already been promoted to the
> older generation and now the JVM may have to do more work to get it garbage
> collected. It is best if object die young (sad but true).
> RedisString has a number of ops that do not use generate a DeltaInfo. But
> they could easily be changed to just generate a DeltaInfo that contains a
> byte array that is the new value of the RedisString. This would even work for
> "setrange" and "setbit" but those could be further optimized to only add a
> subset of the bytes to the DeltaInfo along with an index.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
