Update the implementation of lowoverhead tracing start

This CL changes the implementation to:
1. Allow concurrent starts for long running methods. Long running
method traces run for a specified duration. We allow another trace to
start while the current one is progress. One use case for long running
method traces is to provide better information for analysing ANR
reports. Since there can be overlapping events that we are interested
in, it is important to allow concurrent starts for long running
methods. When a start is requested while a trace is in progress, we
just update the end time of the trace to cover both requests. For the
request that started later, we also see the history from the earlier
start.

2. We no longer wait for the checkpoints to finish when starting the
trace. It is not required to wait for the checkpoints to finish. The
checkpoints are run in order so even in cases where the start-stop-start
sequence happened and the thread hasn't run any of them, it will run
them in order whenever it hits a suspend point. There are two things to
note here:

  1. The trace might start at slightly different times based on when
  the checkpoints are run but that is okay. That is the earliest time
  when we can start the checkpoints anyway.

  2. The RunCheckpoint happens inside a trace_lock_. RunCheckpoint runs
  the checkpoints of the suspended threads before returning. So it
  might take a little longer to finish RunCheckpoint function but that's
  also acceptable since trace_lock_ is only used when a thread is
  exiting and other cases that are not performance critical.

Bug: 352518093
Test: Manual testing using maps app

Change-Id: Id4f415b9393f5f21aa7828a632bf023583a45c25

0 files changed, 0 insertions, 0 deletions