[
https://issues.apache.org/jira/browse/CURATOR-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317370#comment-16317370
]
ASF GitHub Bot commented on CURATOR-447:
----------------------------------------
Github user njhill commented on the issue:
https://github.com/apache/curator/pull/250
Thanks @dragonsinth, there's of course no rush at all!
I agree that `TreeNode extends AtomicReference` isn't a "win" as such, it
just looked cleaner to me than using another `AtomicReferenceFieldUpdater`. But
it's likely subjective and certainly a minor thing.
The `outstandingOps` change seems clearer to me - the field has no use for
most of the life of the cache and yet is incremented/decremented on every
single change. It's not the CPU cycle overhead but more the (CPU) cache
coherency overhead since it's an `AtomicLong`. I didn't think the change
introduces any raciness - the only times when `outstandingOps` needs to be
modified (during initialization or re-initialization) it will be guaranteed to
be non-null.
> I would expect the memory footprint of `ConcurrentMap<String, TreeNode>`
children to mostly dominate the memory overhead of our own classes
Good point. The description of
[CURATOR-374](https://issues.apache.org/jira/browse/CURATOR-374) implied this
might have _some_ mem overhead benefit for very large caches, but removal of
the `nodeState` field was motivated more by state simplification and
consolidation of atomic updates. I'll do some quick measurements but I
acknowledge percentage-wise the saving might not be significant.
> TreeCache: Improve memory usage and concurrent update logic
> -----------------------------------------------------------
>
> Key: CURATOR-447
> URL: https://issues.apache.org/jira/browse/CURATOR-447
> Project: Apache Curator
> Issue Type: Improvement
> Components: Recipes
> Affects Versions: 3.3.0, 2.12.0
> Reporter: Nick Hill
> Priority: Minor
> Labels: performance
>
> Jira https://issues.apache.org/jira/browse/CURATOR-374 reduced per-node
> memory usage in {{TreeCache}}. It can be improved further via removal of the
> {{nodeState}} field - its {{LIVE}} state corresponds exactly to the adjacent
> {{childData}} field being non-null, and a sentinel {{ChildData}} value can be
> used for the {{DEAD}} state. This simplification also reduces the room for
> bugs and state inconsistencies.
> Other improvements included:
> * A further simplification to have {{TreeNode}} extend {{AtomicReference}},
> which obviates the need for an explicit {{childData}} field
> * More robust cache update logic (in get-children and get-data event
> callbacks)
> * Avoid overhead of incrementing/decrementing the {{outstandingOps}} atomic
> integer post-initialization
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
