[jira] [Commented] (CASSANDRA-9379) Use a collection supporting more efficient removal in Ref.GlobalState

["Benedict (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587250#comment-14587250 ] 

Benedict commented on CASSANDRA-9379:
-------------------------------------

For 3.0, I think we should introduce the data structure I linked above, for use in managing Ref states. While CASSANDRA-9549 will be fixed by CLDeque, this data structure still has O(N) modification time. Generally this is fine, but if we have buggy / pathological behaviour again, it would be comforting to know that no operation is slowed down by this. Since the code already exists, and has pretty thorough accompanying test coverage, the labour involved should be minimal.

What would be the preferred way to do this: bring in tree, or publish my artefacts to maven?

> Use a collection supporting more efficient removal in Ref.GlobalState
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-9379
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9379
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Priority: Minor
>
> Ref is intended only to be used in places where there are very few Ref instances against a given object extant at any moment, so this collection does not need to be performant. But to avoid performance regressions, such as accidentally introduced in CASSANDRA-8897 (but avoidable via the scaling back of Ref use, since no longer necessary), we could use a collection that supports more efficient removal.
> I would prefer, however, not to use either of CHM or NBHM, since both are heavyweight objects, wasting a lot of heap; the former is also blocking, and the latter could be problematic for this kind of workload, since it can leave references present in the map after a deletion. The most suitable structure is the one I blogged about [here|http://belliottsmith.com/eventual-consistency-concurrent-data-structures/] and have on github [here|https://github.com/belliottsmith/bes-utils/blob/master/src/bes/concurrent/collections/SimpleCollection.java], since it offers lock-free append and wait-free removal, and ensures space utilization is as low as possible.
> Thoughts/opinions?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)