|
|
--
81f95fcf85b75b84f9892c73123501472b9cff33 by Martijn Vels <mvels@google.com>:
Introduce GetEstimatedMemoryUsage(CordMemoryAccounting::kFairShare)
Memory usage analysis is moved into a separate cord_analysis.cc source.
PiperOrigin-RevId: 416370158
--
6bc7b1348fd27fe53f100c9eabd47f4f2cb9c19c by Abseil Team <absl-team@google.com>:
Support scoped enum in absl::Substitute.
PiperOrigin-RevId: 416345422
--
6399f4f6ae05ebcd67664ebd844902f699ab8ec7 by Abseil Team <absl-team@google.com>:
Correct the computation of contention cycles
Currently, we record contention cycles from the first time a thread started
waiting on a mutex. Consider a situation in which two threads, T1 and T2, run
a loop at the top of which they acquire a common mutex and release it at the
end of the loop body. Further assume that T2 is never able to acquire the
mutex as T1 repeatedly acquires and then releases the mutex. In this case, we
would expect that the reported contention cycles would be increase linearly
over time. But currently we observe a quadratic behavior in the reported
waiting time as mentioned in b/14684244#comment10.
To fix the issue, this CL records the contention cycles experienced by all the threads woken up when the mutex is released. Further, contention_start_cycles is set to the current time since the contention cycles for the time already passed has been taken into account. With this CL, we get a linear increase in the waiting time, the expected behavior.
PiperOrigin-RevId: 416322593
--
149c1637c8a0f1a38e5a8f9f27e5803a2015a554 by Jorg Brown <jorg@google.com>:
Make Status::EmptyString more efficient by constructing it in global space, rather than on the heap. See https://godbolt.org/z/8M9n7YqcY for reduced code size.
PiperOrigin-RevId: 416307833
--
3b4562a8be5a3c80077cb67b0a32c97419058380 by Abseil Team <absl-team@google.com>:
Clarify the usage of RegisterMutexProfiler
PiperOrigin-RevId: 416146130
GitOrigin-RevId: 81f95fcf85b75b84f9892c73123501472b9cff33
Change-Id: Iccb72d7ee617e6ebe226a38170d62e0849b43480
|
Abseil Team