[jira] [Resolved] (IMPALA-5895) Simplify and document memory management of RuntimeProfile Counters

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

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

Tim Armstrong resolved IMPALA-5895.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: Impala 2.11.0


IMPALA-5895: clean up runtime profile lifecycle

Require callers to explicitly stop counter updating instead of doing it
in the destructor. This replaces ad-hoc logic to stop individual
counters.

Track which counters need to be stopped in separate lists instead of
stopping everything.

Force all RuntimeProfiles to use ObjectPools in a uniform way - the
profile, its counters and its children all are allocated from the
same pool. This is done via a new Create() method.

Consolidate 'time_series_counter_map_lock_' and 'counter_map_lock_'
to reduce complexity of the locking scheme. I didn't see any benefit
to sharding the locks in this way - there are only two time series
counters per fragment instance, which a small fraction of the
total number of counters.

Change-Id: I45c39ac36c8e3c277213d32f5ae5f14be6b7f0df
Reviewed-on: http://gerrit.cloudera.org:8080/8069
Reviewed-by: Tim Armstrong <ta...@cloudera.com>
Tested-by: Impala Public Jenkins


> Simplify and document memory management of RuntimeProfile Counters
> ------------------------------------------------------------------
>
>                 Key: IMPALA-5895
>                 URL: https://issues.apache.org/jira/browse/IMPALA-5895
>             Project: IMPALA
>          Issue Type: Improvement
>          Components: Backend
>    Affects Versions: Impala 2.10.0
>            Reporter: Tim Armstrong
>            Assignee: Tim Armstrong
>             Fix For: Impala 2.11.0
>
>
> It's very unclear what requirements there are around object lifetimes for RuntimeProfile objects and the Counter objects that live in ObjectPools. See IMPALA-5878 for a case where it's very hard to reason about correctness of the memory management.
> We should document the requirements and also consider simplifying the ownership model. E.g. having each RuntimeProfile own all of its counters via unique_ptrs. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)