Tag:
Branch:
Tree:
9cdb98e731
lts_2018_06_20
lts_2018_12_18
lts_2019_08_08
lts_2020_02_25
lts_2020_09_23
lts_2021_03_24
lts_2021_11_02
lts_2022_06_23
master
20180600
20181200
20181200.1
20190808
20190808.1
20200225
20200225.1
20200225.2
20200225.3
20200923
20200923.1
20200923.2
20200923.3
20210324.0
20210324.1
20210324.2
20210324.rc1
20211102.0
20211102.rc2
20220623.0
20220623.1
20220623.rc1
${ noResults }
2 Commits (9cdb98e73118f0485fdf5fadcb3e57ab852e65a1)
| Author | SHA1 | Message | Date |
|---|---|---|---|
Abseil Team
|
52d41a9ec2 |
Export of internal Abseil changes
-- 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 |
3 years ago |
|
Abseil Team
|
768eb2ca28 |
Export of internal Abseil changes
-- f012012ef78234a6a4585321b67d7b7c92ebc266 by Laramie Leavitt <lar@google.com>: Slight restructuring of absl/random/internal randen implementation. Convert round-keys.inc into randen_round_keys.cc file. Consistently use a 128-bit pointer type for internal method parameters. This allows simpler pointer arithmetic in C++ & permits removal of some constants and casts. Remove some redundancy in comments & constexpr variables. Specifically, all references to Randen algorithm parameters use RandenTraits; duplication in RandenSlow removed. PiperOrigin-RevId: 312190313 -- dc8b42e054046741e9ed65335bfdface997c6063 by Abseil Team <absl-team@google.com>: Internal change. PiperOrigin-RevId: 312167304 -- f13d248fafaf206492c1362c3574031aea3abaf7 by Matthew Brown <matthewbr@google.com>: Cleanup StrFormat extensions a little. PiperOrigin-RevId: 312166336 -- 9d9117589667afe2332bb7ad42bc967ca7c54502 by Derek Mauro <dmauro@google.com>: Internal change PiperOrigin-RevId: 312105213 -- 9a12b9b3aa0e59b8ee6cf9408ed0029045543a9b by Abseil Team <absl-team@google.com>: Complete IGNORE_TYPE macro renaming. PiperOrigin-RevId: 311999699 -- 64756f20d61021d999bd0d4c15e9ad3857382f57 by Gennadiy Rozental <rogeeff@google.com>: Switch to fixed bytes specific default value. This fixes the Abseil Flags for big endian platforms. PiperOrigin-RevId: 311844448 -- bdbe6b5b29791dbc3816ada1828458b3010ff1e9 by Laramie Leavitt <lar@google.com>: Change many distribution tests to use pcg_engine as a deterministic source of entropy. It's reasonable to test that the BitGen itself has good entropy, however when testing the cross product of all random distributions x all the architecture variations x all submitted changes results in a large number of tests. In order to account for these failures while still using good entropy requires that our allowed sigma need to account for all of these independent tests. Our current sigma values are too restrictive, and we see a lot of failures, so we have to either relax the sigma values or convert some of the statistical tests to use deterministic values. This changelist does the latter. PiperOrigin-RevId: 311840096 GitOrigin-RevId: f012012ef78234a6a4585321b67d7b7c92ebc266 Change-Id: Ic84886f38ff30d7d72c126e9b63c9a61eb729a1a |
5 years ago |