Dump java backtrace when contending lock too long time.
It’s easy to cause a problem when execute time-consuming work inside
a synchronized method/block. Previously, we use "dvm_lock_sample" in
event log to help us look into.
But it's always after the event, "dvm_lock_sample" is printed after the
owner thread exited the critical section, we don't know more details
that which statement get stuck or more time-consuming.
This implementation provides a lot more information about what the
contending thread is doing. when a thread contend for a long time,
we will print backtrack which thread holding the lock.
Maybe many threads waiting this lock, those threads will request
printing backtrack many times, which is helpful for finding and
locating problems.
This mechanism is only suitable for very long wait times, not lots of
short wait times.
This feature is heavyweight, it's not enabled by default. we can
turn on by "-XX:MonitorTimeoutEnable" in AndroidRuntime::startVm.
Bug:140968481
Test: Manually check contention log messages.
Signed-off-by: wangguibo <wangguibo@xiaomi.com>
Change-Id: I29784d11355ae3c581723254848a87cd80e71456
Merged-In: I29784d11355ae3c581723254848a87cd80e71456
(cherry picked from commit 0d290721a8d63d5e0d38a64d3ecf922a91becb10)
10 files changed
