diff options
| author | 2024-02-27 14:54:51 +0000 | |
|---|---|---|
| committer | 2024-02-28 09:29:35 +0000 | |
| commit | 5c4f3e5e8b1031ab112e273620e2b2cb89432d57 (patch) | |
| tree | c40fe3ae657dc55d6d870d8f140c5e342414069a /test/MultiDexModifiedSecondary/main.jpp | |
| parent | 8533e7b40d0dff78aaaf44a6506a7dabd37bfd45 (diff) | |
Fixes around flushing per-thread tracing buffer
We should never see a non-nullptr in the thread destructor. We should
flush the buffer in Thread::Destroy. This CL has the following fixes:
1. Update the Thread::~Thread to check that the per-thread method trace
buffer is nullptr instead of handling it by deleting it.
2. Flush the buffer at a later point to avoid the possibility of any
java code executing and re-allocating the buffer after we flushed the
contents.
3. Remove the potential race between Trace::Stop and Thread::Destroy
when flushing the trace buffer. We now take the tracing_lock_ lock
earlier in Trace::Stop. Trace::Stop flushes all the buffers and
resets the trace_ under the tracing_lock_. Thread::Destroy already
takes the tracing_lock_ before flushing the buffer. So we make sure
only one of them flushes the contents.
4. Also reset the buffer index when resetting the per-thread buffer.
Otherwise JITed code could incorrectly assume there is a buffer
allocated. JITed code avoids a nullptr check on the buffer to make it
more efficient.
Bug: 326890292
Test: art/test.py --trace --stream
Change-Id: Ifebaa8498817a248689730ac3cfe7cc8a74d4e1a
Diffstat (limited to 'test/MultiDexModifiedSecondary/main.jpp')
0 files changed, 0 insertions, 0 deletions