string-matcher: reduce per-matcher memory by adisuissa · Pull Request #37782 · envoyproxy/envoy

adisuissa · 2024-12-20T16:00:14Z

Commit Message: string-matcher: reduce per-matcher memory
Additional Description:
This is similar to #37324 but doesn't use virtual functions (uses std::variant instead).
These are the goals for this new StringMatcherImpl class:

improve encapsulation and use polymorphism that will make the code a bit more readable.
reduce the amount of memory used by the StringMatcher (e.g., an object of type ExactStringMatcher doesn't need to also hold a pointer to a regex object).
reduce the amount of memory that is essentially repeated (removing the kept protobuf matcher object that holds redundant information).
replace the uses of the matcher() that are needed to find the contents of the string-matcher by introducing the stringRepresentation() method.

A simple test showed that for 1000 perfix (non-regex) matchers, the new approach reduced the amount of memory from 570368 to 530176 bytes (~40KiB).
For a case of 1000 regex-matchers with a varying length of prefix (1-1001), the new approach reduced the amount of memory from 15671616 to 15021632 bytes (~635KiB).

Compared to #37324, this version enjoys the inlining compiler optimizations that can be made when virtual tables aren't used. The downside is the use of std::variant, which may require a bit more memory, and results in a more coupled code for the string matchers, but IMHO it improves upon the current implementation.

Risk Level: low - not being used at the moment (but future PRs will).
Testing: duplicated the tests needed
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

repokitteh-read-only · 2024-12-20T16:00:20Z

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #37782 was opened by adisuissa.

see: more, trace.

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

…rnative Signed-off-by: Adi Suissa-Peleg <adip@google.com>

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

adisuissa · 2024-12-23T22:06:07Z

I've executed the router_config_impl_speed_test, using the following:
bazel build -c opt //test/common/router:config_impl_speed_test --config=libc++
and then executing:
taskset 0x1000 bazel-bin/test/common/router/config_impl_speed_test --benchmark_repetitions=10 --benchmark_out=output.csv --benchmark_out_format=csv

and got the following results - showing only the mean of each 10 runs, and the second column is "diff%" (negative number implies that the new version is better - less time, positive number implies that the original version is better):

name	diff% ( (NEW-ORIGINAL)/ORIGINAL)*100 )	Orig Real time	Orig CPU time	New Real time	New CPU time
bmRouteTableSizeWithPathPrefixMatch/1_mean	-0.665188	903	902	897	896
bmRouteTableSizeWithPathPrefixMatch/2_mean	-0.306748	979	978	976	975
bmRouteTableSizeWithPathPrefixMatch/4_mean	-1.40845	1137	1136	1121	1120
bmRouteTableSizeWithPathPrefixMatch/8_mean	-2.43031	1400	1399	1366	1365
bmRouteTableSizeWithPathPrefixMatch/16_mean	-3.62615	1959	1958	1889	1887
bmRouteTableSizeWithPathPrefixMatch/32_mean	-5.44506	3070	3067	2902	2900
bmRouteTableSizeWithPathPrefixMatch/64_mean	-7.57405	5339	5334	4935	4930
bmRouteTableSizeWithPathPrefixMatch/128_mean	-8.4785	9940	9931	9098	9089
bmRouteTableSizeWithPathPrefixMatch/256_mean	-9.862	19296	19276	17391	17375
bmRouteTableSizeWithPathPrefixMatch/512_mean	-10.0741	37534	37492	33745	33715
bmRouteTableSizeWithPathPrefixMatch/1024_mean	-13.3069	82592	82506	71590	71527
bmRouteTableSizeWithPathPrefixMatch/2048_mean	-10.5528	174332	174086	155859	155715
bmRouteTableSizeWithPathPrefixMatch/4096_mean	-6.591	333067	332787	311163	310853
bmRouteTableSizeWithPathPrefixMatch/8192_mean	-5.59905	635485	634911	599967	599362
bmRouteTableSizeWithPathPrefixMatch/16384_mean	-8.94865	1301248	1299905	1184862	1183581
bmRouteTableSizeWithExactPathMatch/1_mean	-0.775194	904	903	897	896
bmRouteTableSizeWithExactPathMatch/2_mean	-0.817996	979	978	971	970
bmRouteTableSizeWithExactPathMatch/4_mean	-1.67401	1136	1135	1117	1116
bmRouteTableSizeWithExactPathMatch/8_mean	-2.64097	1403	1401	1366	1364
bmRouteTableSizeWithExactPathMatch/16_mean	-3.71501	1968	1965	1893	1892
bmRouteTableSizeWithExactPathMatch/32_mean	-5.85192	3096	3093	2914	2912
bmRouteTableSizeWithExactPathMatch/64_mean	-8.63469	5425	5420	4957	4952
bmRouteTableSizeWithExactPathMatch/128_mean	-9.28869	10076	10066	9140	9131
bmRouteTableSizeWithExactPathMatch/256_mean	-9.07519	19105	19085	17368	17353
bmRouteTableSizeWithExactPathMatch/512_mean	-7.7453	36615	36577	33777	33744
bmRouteTableSizeWithExactPathMatch/1024_mean	-9.8651	79410	79320	71564	71495
bmRouteTableSizeWithExactPathMatch/2048_mean	-7.65469	175864	175644	162343	162199
bmRouteTableSizeWithExactPathMatch/4096_mean	-3.29229	322320	321964	311665	311364
bmRouteTableSizeWithExactPathMatch/8192_mean	-4.08471	628595	627609	602605	601973
bmRouteTableSizeWithExactPathMatch/16384_mean	-6.73461	1270351	1268997	1184974	1183535
bmRouteTableSizeWithRegexMatch/1_mean	0.0958773	1044	1043	1045	1044
bmRouteTableSizeWithRegexMatch/2_mean	0.475059	1264	1263	1270	1269
bmRouteTableSizeWithRegexMatch/4_mean	1.04615	1626	1625	1644	1642
bmRouteTableSizeWithRegexMatch/8_mean	0.121902	2463	2461	2466	2464
bmRouteTableSizeWithRegexMatch/16_mean	-0.735622	4491	4486	4460	4453
bmRouteTableSizeWithRegexMatch/32_mean	-0.597356	7876	7868	7829	7821
bmRouteTableSizeWithRegexMatch/64_mean	-0.135291	14806	14783	14777	14763
bmRouteTableSizeWithRegexMatch/128_mean	-0.0775874	29672	29644	29652	29621
bmRouteTableSizeWithRegexMatch/256_mean	2.34694	58304	58246	59673	59613
bmRouteTableSizeWithRegexMatch/512_mean	-2.26124	182966	182776	178829	178643
bmRouteTableSizeWithRegexMatch/1024_mean	2.46927	391451	391006	401057	400661
bmRouteTableSizeWithRegexMatch/2048_mean	-1.02613	565276	564648	559373	558854
bmRouteTableSizeWithRegexMatch/4096_mean	-0.588469	1104409	1103201	`1098546`	1096709
bmRouteTableSizeWithRegexMatch/8192_mean	-6.25331	2668977	2666013	2501743	2499299
bmRouteTableSizeWithRegexMatch/16384_mean	-1.14446	8314663	8306593	8220362	8211527
bmRouteTableSizeWithExactMatcherTree/1_mean	1.95412	1178	1177	1201	1200
bmRouteTableSizeWithExactMatcherTree/2_mean	1.95412	1178	1177	1201	1200
bmRouteTableSizeWithExactMatcherTree/4_mean	2.04255	1176	1175	1200	1199
bmRouteTableSizeWithExactMatcherTree/8_mean	2.04255	1176	1175	1200	1199
bmRouteTableSizeWithExactMatcherTree/16_mean	1.34794	1188	1187	1205	1203
bmRouteTableSizeWithExactMatcherTree/32_mean	1.51643	1188	1187	1206	1205
bmRouteTableSizeWithExactMatcherTree/64_mean	1.34794	1188	1187	1204	1203
bmRouteTableSizeWithExactMatcherTree/128_mean	1.43218	1189	1187	1205	1204
bmRouteTableSizeWithExactMatcherTree/256_mean	1.17845	1189	1188	1203	1202
bmRouteTableSizeWithExactMatcherTree/512_mean	1.26263	1189	1188	1204	1203
bmRouteTableSizeWithExactMatcherTree/1024_mean	1.34907	1187	1186	1204	1202
bmRouteTableSizeWithExactMatcherTree/2048_mean	2.02703	1186	1184	1209	1208
bmRouteTableSizeWithExactMatcherTree/4096_mean	1.17944	1188	1187	1202	1201
bmRouteTableSizeWithExactMatcherTree/8192_mean	1.34907	1187	1186	1203	1202
bmRouteTableSizeWithExactMatcherTree/16384_mean	0.674536	1187	1186	1195	1194
bmRouteTableSizeWithPrefixMatcherTree/1_mean	1.26796	1184	1183	1199	1198
bmRouteTableSizeWithPrefixMatcherTree/2_mean	1.35135	1185	1184	1202	1200
bmRouteTableSizeWithPrefixMatcherTree/4_mean	1.86757	1179	1178	1201	1200
bmRouteTableSizeWithPrefixMatcherTree/8_mean	2.03735	1180	1178	1203	1202
bmRouteTableSizeWithPrefixMatcherTree/16_mean	1.86916	1178	1177	1200	1199
bmRouteTableSizeWithPrefixMatcherTree/32_mean	2.03562	1181	1179	1205	1203
bmRouteTableSizeWithPrefixMatcherTree/64_mean	1.7842	1178	1177	1200	1198
bmRouteTableSizeWithPrefixMatcherTree/128_mean	1.01095	1189	1187	1200	1199
bmRouteTableSizeWithPrefixMatcherTree/256_mean	0.670578	1194	1193	1203	1201
bmRouteTableSizeWithPrefixMatcherTree/512_mean	0.671141	1194	1192	1201	1200
bmRouteTableSizeWithPrefixMatcherTree/1024_mean	0.671704	1192	1191	1201	1199
bmRouteTableSizeWithPrefixMatcherTree/2048_mean	0.672269	1191	1190	1199	1198
bmRouteTableSizeWithPrefixMatcherTree/4096_mean	0.925926	1189	1188	1200	1199
bmRouteTableSizeWithPrefixMatcherTree/8192_mean	0.92437	1191	1190	1203	1201
bmRouteTableSizeWithPrefixMatcherTree/16384_mean	0.756303	1191	1190	1200	1199

combined_route_config_impl_speed_test_10_mean.csv

IMHO, and from running a few more tests, I've observed that these tests are somewhat noisy, and there's no clear winner.
All results seems to be within the margin of error, and not much execution time difference is observed.

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

…rnative Signed-off-by: Adi Suissa-Peleg <adip@google.com>

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

jmarantz · 2025-01-05T22:13:15Z

Do you have stats on the memory usage improvement?

adisuissa · 2025-01-06T14:24:41Z

Do you have stats on the memory usage improvement?

It depends :)
The size of each StringMatcher structure was reduced from 96 to 64 bytes - not much, but if this reduces the amount of memory for all string and path matchers.
For StringMatchers of regex type, the memory is essentially halved (no longer keeping the original string in the matcher_ proto data-member).

jmarantz · 2025-01-06T14:30:33Z

Are you able to confirm that size reduction using a memory test a la

envoy/test/common/stats/symbol_table_impl_test.cc

Line 783 in 2aaa544

EXPECT_MEMORY_LE(symbol_table_mem_used, string_mem_used / 3);

yanavlasov · 2025-01-07T15:36:46Z

/wait-any

adisuissa · 2025-01-07T16:01:35Z

Are you able to confirm that size reduction using a memory test a la

envoy/test/common/stats/symbol_table_impl_test.cc

Line 783 in 2aaa544

EXPECT_MEMORY_LE(symbol_table_mem_used, string_mem_used / 3);

Seems that the stats test validates 2 things:

That compared to std::string the StatNmaeStorage uses less memory, and
That the use of some predefined list of stat names consumes a certain amount of memory when StatNameStorage is used.

In the current PR we are replacing a class that has multiple data members with an std::variant (union).
As this is a replacement of the class I'm not sure there's a straight way to achieve (1), unless we keep the old class.
If the goal is to show that with the PR changes the Regex memory used is reduced, then I guess we can introduce 2 classes in the tests:

struct Old {
  envoy::type::matcher::v3::StringMatcher porto_; // Initialized with regex pattern
  Regex::CompiledMatcherPtr regex_; // Initialized with the regex pattern
}

and

struct New {
  Regex::CompiledMatcherPtr regex_; // Initialized with the regex pattern
}

And show that the memory is halved, but I'm not sure if that gains much.
If I misunderstood your request, please let me know.

adisuissa · 2025-02-06T03:28:28Z

Apologies, @jmarantz I've replied to this comment above:

The test doesn't have any expectations (assertions) and I don't think it should. IMHO adding memory usage expectations is useful in cases where one wants to limit future additions/changes to the current data-structure (or make it clear that this change should be highly scrutinized). I don't think this is the current case, but willing to hear other thoughts on this.

If you think that these are "strict" memory expectations I can add the tests.

jmarantz · 2025-02-06T04:36:02Z

I missed that. I don't think it's "strict" but it is useful to get notified a change might increase memory usage. If that's justified then then author can change the expectation, but they'll be constant.

And it will document more formally in our codebase what the memory use is.

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

yanavlasov

LGTM. Memory tests were added

adisuissa · 2025-02-06T19:00:04Z

@jmarantz I've added the memory tests in a3694e3

I found it interesting that when running locally I've received a non-canonical platform test skipped message:

[2025-02-06 14:48:46.421][16][info][misc] [test/common/common/matchers_test.cc:475] Skipping exact memory test of actual=530176 versus expected=530176 bytes as platform is non-canonical

TBH, I'm not sure this has been actually executed by any test environment that uses the EXPECT_MEMORY_EQ expectation.
More specifically, IIUC, the call to mode() would never return a canonical mode (see code).

Just highlighting that this may be broken, and we should probably fix this... but not as part of this PR.

jmarantz · 2025-02-06T19:15:30Z

Can you switch to using EXPECT_MEMORY_LE ?

I think that should be better supported -- test it by making an impossibly low target and verifying it fails.

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

…rnative Signed-off-by: Adi Suissa-Peleg <adip@google.com>

adisuissa · 2025-02-06T20:27:41Z

Can you switch to using EXPECT_MEMORY_LE ?

I think that should be better supported -- test it by making an impossibly low target and verifying it fails.

I've updated the tests. Due to non-determinism of tcmalloc memory consumption estimation, I had to add a buffer to the tests thresholds estimations.
Let's see that it passes CI, as I assume that there may be compiler/architecture interactions that may fail these tests in some scenarios.

This is similar to #37324 but doesn't use virtual functions (uses std::variant instead). These are the goals for this new StringMatcherImpl class: 1. improve encapsulation and use polymorphism that will make the code a bit more readable. 2. reduce the amount of memory used by the StringMatcher (e.g., an object of type ExactStringMatcher doesn't need to also hold a pointer to a regex object). 3. reduce the amount of memory that is essentially repeated (removing the kept protobuf matcher object that holds redundant information). 4. replace the uses of the [matcher()](https://github.com/envoyproxy/envoy/blob/9aad3320cf58a19cb4bbbbbaa357dbedf8715900/source/common/common/matchers.h#L157) that are needed to find the contents of the string-matcher by introducing the stringRepresentation() method. A [simple test](envoyproxy/envoy#37782 (comment)) showed that for 1000 perfix (non-regex) matchers, the new approach reduced the amount of memory from 570368 to 530176 bytes (~40KiB). For a case of 1000 regex-matchers with a varying length of prefix (1-1001), the new approach reduced the amount of memory from 15671616 to 15021632 bytes (~635KiB). Compared to #37324, this version enjoys the inlining compiler optimizations that can be made when virtual tables aren't used. The downside is the use of std::variant, which may require a bit more memory, and results in a more coupled code for the string matchers, but IMHO it improves upon the current implementation. Risk Level: low - not being used at the moment (but future PRs will). Testing: duplicated the tests needed Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A --------- Signed-off-by: Adi Suissa-Peleg <adip@google.com>

…asserts Remove the tcmalloc-consumedBytes-based TEST_F(StringMatcher, Memory) which was producing ~5/1000 flakes on gcc CI (page-level allocation jitter, hard-coded constants needing manual updates on every dep bump). Replace with: - Compile-time static_asserts on sizeof(ExactStringMatcher), PrefixStringMatcher, SuffixStringMatcher, ContainsStringMatcher, RegexStringMatcher, CustomStringMatcher, and StringMatcherImpl, expressed in terms of sizeof(std::string) + sizeof(void*) so they are portable across libc++/libstdc++ and 32-/64-bit builds. These fire deterministically at compile time if someone adds an unused field to any variant alternative. - A runtime TEST_F(StringMatcher, SizeIsBounded) that mirrors the static_asserts so the bounds are visible in test-runner output. - A comment block explaining why the old test was removed and what structural property the new assertions enforce, pointing back to PR #37782. Agent-Logs-Url: https://github.com/envoyproxy/envoy/sessions/6c75cfb3-7651-4bd2-9682-cb5b74325ac0 Co-authored-by: phlax <454682+phlax@users.noreply.github.com>

…unds (#44701) Replaces `TEST_F(StringMatcher, Memory)` with `StringMatcher.SizeIsBounded`. The old test asserted tcmalloc page-level `consumedBytes()` against hand-tuned ceilings, which produced ~5/1000 CI flakes and had to be re-tuned on every tcmalloc/abseil/protobuf bump (#37782, #43467). The new test bounds `sizeof` of each variant alternative and of `StringMatcherImpl` itself, expressed in `sizeof(std::string)` / `sizeof(void*)` for libc++ / libstdc++ portability. Same intent as #37782, deterministic. --------- Signed-off-by: Ryan Northey <ryan@synca.io>

…unds (envoyproxy#44701) Replaces `TEST_F(StringMatcher, Memory)` with `StringMatcher.SizeIsBounded`. The old test asserted tcmalloc page-level `consumedBytes()` against hand-tuned ceilings, which produced ~5/1000 CI flakes and had to be re-tuned on every tcmalloc/abseil/protobuf bump (envoyproxy#37782, envoyproxy#43467). The new test bounds `sizeof` of each variant alternative and of `StringMatcherImpl` itself, expressed in `sizeof(std::string)` / `sizeof(void*)` for libc++ / libstdc++ portability. Same intent as --------- Signed-off-by: Ryan Northey <ryan@synca.io>

…unds (envoyproxy#44701) Replaces `TEST_F(StringMatcher, Memory)` with `StringMatcher.SizeIsBounded`. The old test asserted tcmalloc page-level `consumedBytes()` against hand-tuned ceilings, which produced ~5/1000 CI flakes and had to be re-tuned on every tcmalloc/abseil/protobuf bump (envoyproxy#37782, envoyproxy#43467). The new test bounds `sizeof` of each variant alternative and of `StringMatcherImpl` itself, expressed in `sizeof(std::string)` / `sizeof(void*)` for libc++ / libstdc++ portability. Same intent as envoyproxy#37782, deterministic. --------- Signed-off-by: Ryan Northey <ryan@synca.io>

…unds (envoyproxy#44701) Replaces `TEST_F(StringMatcher, Memory)` with `StringMatcher.SizeIsBounded`. The old test asserted tcmalloc page-level `consumedBytes()` against hand-tuned ceilings, which produced ~5/1000 CI flakes and had to be re-tuned on every tcmalloc/abseil/protobuf bump (envoyproxy#37782, envoyproxy#43467). The new test bounds `sizeof` of each variant alternative and of `StringMatcherImpl` itself, expressed in `sizeof(std::string)` / `sizeof(void*)` for libc++ / libstdc++ portability. Same intent as --------- Signed-off-by: Ryan Northey <ryan@synca.io>

…unds (#44701) Replaces `TEST_F(StringMatcher, Memory)` with `StringMatcher.SizeIsBounded`. The old test asserted tcmalloc page-level `consumedBytes()` against hand-tuned ceilings, which produced ~5/1000 CI flakes and had to be re-tuned on every tcmalloc/abseil/protobuf bump (#37782, #43467). The new test bounds `sizeof` of each variant alternative and of `StringMatcherImpl` itself, expressed in `sizeof(std::string)` / `sizeof(void*)` for libc++ / libstdc++ portability. Same intent as --------- Signed-off-by: Ryan Northey <ryan@synca.io>

…unds (#44701) Replaces `TEST_F(StringMatcher, Memory)` with `StringMatcher.SizeIsBounded`. The old test asserted tcmalloc page-level `consumedBytes()` against hand-tuned ceilings, which produced ~5/1000 CI flakes and had to be re-tuned on every tcmalloc/abseil/protobuf bump (#37782, #43467). The new test bounds `sizeof` of each variant alternative and of `StringMatcherImpl` itself, expressed in `sizeof(std::string)` / `sizeof(void*)` for libc++ / libstdc++ portability. Same intent as #37782, deterministic. --------- Signed-off-by: Ryan Northey <ryan@synca.io>

string-matcher: reduce per-matcher memory

50f8f1d

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

adisuissa added 5 commits December 20, 2024 16:36

addressing CI errors

247a58f

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

Merge remote-tracking branch 'upstream/main' into string_matcher_alte…

6527817

…rnative Signed-off-by: Adi Suissa-Peleg <adip@google.com>

CI issues

a50f1d5

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

tests

14320a5

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

fix oauth2 test

0186a85

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

adisuissa added 3 commits January 2, 2025 20:58

improve coverage

3a1fbf2

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

Merge remote-tracking branch 'upstream/main' into string_matcher_alte…

86d4cb1

…rnative Signed-off-by: Adi Suissa-Peleg <adip@google.com>

coverage test fix

d1baf1f

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

adisuissa marked this pull request as ready for review January 3, 2025 04:10

adisuissa requested review from botengyao, jmarantz, mattklein123, soulxu, tyxia, wbpcode, yanavlasov and zuercher as code owners January 3, 2025 04:10

ravenblackx assigned yanavlasov Jan 3, 2025

removing unnecessary GCOVR_EXCL_LINE as they don't impact coverage

05cd337

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

adisuissa mentioned this pull request Jan 6, 2025

string-matcher: introduce OO string-matcher prior to refactor #37324

Closed

repokitteh-read-only Bot added the waiting:any label Jan 7, 2025

repokitteh-read-only Bot removed the waiting:any label Jan 7, 2025

adding memory tests

a3694e3

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

adisuissa dismissed yanavlasov’s stale review via a3694e3 February 6, 2025 14:51

yanavlasov previously approved these changes Feb 6, 2025

View reviewed changes

yanavlasov enabled auto-merge (squash) February 6, 2025 16:36

adisuissa added 2 commits February 6, 2025 20:24

memory tests are now working, but memory estimation is flaky

feb84c1

Signed-off-by: Adi Suissa-Peleg <adip@google.com>

Merge remote-tracking branch 'upstream/main' into string_matcher_alte…

cf2d5f9

…rnative Signed-off-by: Adi Suissa-Peleg <adip@google.com>

adisuissa dismissed yanavlasov’s stale review via cf2d5f9 February 6, 2025 20:25

jmarantz approved these changes Feb 7, 2025

View reviewed changes

yanavlasov merged commit dc3b061 into envoyproxy:main Feb 7, 2025

Copilot AI mentioned this pull request Apr 28, 2026

test: replace flaky StringMatcher.Memory with deterministic sizeof static_asserts #44699

Closed

phlax mentioned this pull request Apr 28, 2026

test: replace flaky StringMatcher.Memory with deterministic sizeof bounds #44701

Merged

Copilot AI mentioned this pull request Apr 28, 2026

test/access_loggers/stats: replace tcmalloc consumedBytes assertions with sizeof structural bounds #44708

Closed

Conversation

adisuissa commented Dec 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

repokitteh-read-only Bot commented Dec 20, 2024

Uh oh!

adisuissa commented Dec 23, 2024

Uh oh!

jmarantz commented Jan 5, 2025

Uh oh!

adisuissa commented Jan 6, 2025

Uh oh!

jmarantz commented Jan 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yanavlasov commented Jan 7, 2025

Uh oh!

adisuissa commented Jan 7, 2025

Uh oh!

adisuissa commented Feb 6, 2025

Uh oh!

jmarantz commented Feb 6, 2025

Uh oh!

yanavlasov left a comment

Choose a reason for hiding this comment

Uh oh!

adisuissa commented Feb 6, 2025

Uh oh!

jmarantz commented Feb 6, 2025

Uh oh!

adisuissa commented Feb 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

adisuissa commented Dec 20, 2024 •

edited

Loading

jmarantz commented Jan 6, 2025 •

edited

Loading