Control: tags -1 + moreinfo
On Mon, 21 Nov 2022 at 01:59:09 +0100, Santiago Vila wrote:
> During a mass rebuild of all packages in bookworm, I noticed that gjs
> allocates up to 237 GB of memory.
When I upload it, I do my test-build in a VM with 2G of RAM, and that
works fine. I'm using a bullseye VM containing bullseye's sbuild and
schroot, with gjs built in a sid chroot by that copy of sbuild. This
is intended to replicate Debian's production buildds as closely as is
feasible to do on a laptop, because what matters for typical Debian users
is whether the package is built successfully and correctly on the buildds.
In case there's a kernel difference, I've just tried it in a bookworm
VM containing bookworm's sbuild and schroot, again with 2G of RAM. That
was also successful.
I've had trouble with some larger GNOME-related packages in this
environment (if I remember correctly, I need to allocate 6G for mozjs102,
and mutter has sometimes needed 4G) but gjs itself seems fine in 2G.
This is with DEB_BUILD_OPTIONS=parallel=4. Because it's C++, it will
likely need more RAM if you have a very large number of CPUs (but not
as much as a monster like WebKit or mozjs).
If there's a unit test that intentionally tries to provoke an
out-of-memory situation to check that gjs handles that correctly, then
that might be what's allocating so much RAM? I don't immediately see any
such tests, though.
> I measure this by monitoring Committed_AS parameter in /proc/meminfo at
> every second during the build.
I think you might accidentally be measuring how much it *can* allocate
if given the opportunity, as opposed to how much it strictly *needs*
to allocate?
smcv
