impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Armstrong (Code Review)" <ger...@cloudera.org>
Subject [Impala-ASF-CR] IMPALA-5715: (mitigation only) defer destruction of MemTrackers
Date Fri, 04 Aug 2017 00:36:48 GMT
Tim Armstrong has posted comments on this change.

Change subject: IMPALA-5715: (mitigation only) defer destruction of MemTrackers
......................................................................


Patch Set 2:

(4 comments)

http://gerrit.cloudera.org:8080/#/c/7492/2/be/src/runtime/buffered-block-mgr.cc
File be/src/runtime/buffered-block-mgr.cc:

PS2, Line 568:   mem_tracker_->UnregisterFromParent();
> I don't think you have to UnregisterFromParent here, since the query-state 
I think fixing this is non-trivial, since we call ~BufferedBlockMgr() from RuntimeState::ReleaseResources(),
which can happen before query teardown.

Hopefully we're deleting this file in a couple of days anyway :).

I explained that it was only used from the query MemTracker and added a TODO to update it.


http://gerrit.cloudera.org:8080/#/c/7492/2/be/src/runtime/mem-tracker.cc
File be/src/runtime/mem-tracker.cc:

PS2, Line 200: May not have been closed yet.
> why not?
Lots of backend tests rely on the destructor cleaning these up. It's a pretty big task to
go through and fix them all. Updated the comment to be more specific.


http://gerrit.cloudera.org:8080/#/c/7492/2/be/src/runtime/mem-tracker.h
File be/src/runtime/mem-tracker.h:

PS2, Line 105:   /// Deregisters the MemTracker from it's parent. Can be called after Close()
and before
             :   /// destruction to prevent other threads from getting a reference to the
MemTracker via
             :   /// its parent.
> I think we can simplify the protocol further: I think this can be be called
I'm not sure if I understood the exact suggestion. I combined this with Close() instead of
requiring the two methods be called in sequence.


http://gerrit.cloudera.org:8080/#/c/7492/2/be/src/runtime/runtime-state.cc
File be/src/runtime/runtime-state.cc:

Line 260: void RuntimeState::ReleaseResources() {
> This function doesn't appear to be idempotent right now, looks like calling
I think it's mostly depended on what was simpler in context - in a lot of places the code
is simpler if we call Close() unconditionally.

This one only has a single callsite so there's no reason to think that we'd call it twice.


-- 
To view, visit http://gerrit.cloudera.org:8080/7492
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I205abb0076d1ffd08cb93c0f1671c8b81e7fba0f
Gerrit-PatchSet: 2
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Tim Armstrong <tarmstrong@cloudera.com>
Gerrit-Reviewer: Henry Robinson <henry@cloudera.com>
Gerrit-Reviewer: Matthew Jacobs <mj@cloudera.com>
Gerrit-Reviewer: Michael Ho <kwho@cloudera.com>
Gerrit-Reviewer: Tim Armstrong <tarmstrong@cloudera.com>
Gerrit-HasComments: Yes

Mime
View raw message