[Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848

--- Comment #12 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
Just to add to the examples of what it takes
to build and link gmock-matchers_test . . .

In /usr/src/lib/googletest/gmock_main/tests/ I tried
building gmock-matchers_test on an Orange Pi+ 2ed
(armv7 Cortex-A7 with 2 GiBytes of RAM and 1740Mi
swap/paging space). The context is head -r358132 .

I use a modified version of top that keeps track of
its sampled "Max. Observed Active" (MaxObsActive),
MaxObsWired, MaxObs(Act+Wir), and, for swap use,
MaxObsUsed (if any). It is also biased to present
more digits (smaller unit size) and be explicit
about powers of 2 factors being in use for memory
size display.

After finishing in somewhat over 20 minutes (under 25?),
the odd variant of top was showing:

1019Mi MaxObsActive, 193444Ki MaxObsWired, 1146Mi MaxObs(Act+Wir)
Swap: 1740Mi Total, 1740Mi Free

That spans the link as well. So swap/paging space was not observed
to be used --but clearly would have been on a 1 GiByte machine.
Similarly Free RAM was never observed to be low but would have
been on a 1 GiByte machine.

An example aarch64 is a Rock64 (not Pro) with 4 GiBytes of RAM:

1753Mi MaxObsActive, 633084Ki MaxObsWired, 2368Mi MaxObs(Act+Wir)
Swap: 4608Mi Total, 4608Mi Free

(It shows a lot more Wired even without the build, just because of
the larger amount of RAM.) So, even just looking at the MaxObsActive,
it indicates that a 1 GiByte RAM machine would be paging/swaping and
a 2 GiByte machine would likely do some as well (far less).

There is a significant MaxObsActive difference between the armv7 and
aarch64 contexts. But it would be interesting to see what a 2 GiByte
aarch64 would be like.

-- 
You are receiving this mail because:
You are the assignee for the bug.