Allow RunCheckpoint to lock mutator repeatedly

Add an option to RunCheckpoint to acquire the mutator lock separately
for each suspended-thread checkpoint function we run. This avoids
keeping the initiating thread runnable, and unable to respond to suspend
requests. for the entire duration of dump generation. Otherwise that can
generate substantial jank, and suspend timeouts.

Modify ThreadList::Dump to use this version.

Replace the ScopedObjectAccess in DumpCheckpoint::Run() with an
assertion that we already hold the mutator lock.

This largely reverts aosp/238341. We believe that the deadlocks
motivating that were already made impossible by the more recent thread
suspension rewrite.

This weakens undocumented semantics of RunCheckpoints, and instead
documents the properties we actually do guarantee. Previously we
guaranteed that every thread existing at the RunCheckpoint call
either runs the checkpoint, or it was subsequently created by
a parent thread satisfying this property. I.e. we ensured
that each thread that subsequently ran either ran the checkpoint
itself, or had an ancestor that did. We do not believe this
was ever relied upon.

Bug: 333708482
Test: Treehugger
Change-Id: Ief098b89e96bb647914bca4e467bca15971553cd

0 files changed, 0 insertions, 0 deletions