Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into believing it's the
root of their problems.
The only way left to force the slice allocator to use "system" malloc (in
practice, jemalloc) is to set the G_SLICE environment variable to
always-malloc, and that needs to happen before glib is loaded.
Fortunately, the firefox and plugin-container executables don't depend on
glib. Unfortunately, webapprt does, so the problem remains for web apps
running through it. xpcshell and other executables that depend on libxul
directly (as opposed to loading it dynamically) are not covered either.
Constructing kComponentsInterfaceShimMap required a static constructor
on some compilers, due to a non-constexpr constructor and the necessity
of copying non-constexpr things like nsIID. This static constructor is
large (several kilobytes of object code on x86-64) and completely
unnecessary.
To fix this, let's add a constexpr (well, MOZ_CONSTEXPR) constructor to
ComponentsInterfaceShimEntry. This change alone doesn't completely
solve our problem, because the nsIID member still needs to be copied.
But doing that copying is silly: we only use the IID for constructing a
ShimInterfaceInfo in ShimInterfaceInfo::MaybeConstruct, and the
ShimInterfaceInfo constructor takes a const reference. So let's store a
const reference in ComponentsInterfaceShimEntry, too, and make that
structure significantly smaller in the process.
PostTimerEvent is only called by the timer thread, which is already able
to access private members of nsTimerImpl; there's no reason for
PostTimerEvent to be public.
GetTracedTask() is only called from nsTimerImpl itself, so it doesn't
need to be public. GetTLSTraceInfo() is called from the timer thread,
which has access to our private members already.
This patch factors out the existing capacity calculation code in HashShift()
into a new function called BestCapacity(), and then reuses it for
post-enumeration shrinking.
BestCapacity() computes capacity with |CeilingLog2(ceil(length * 4 / 3))|,
which ensures a minimum capacity while respecting the "max 75% full" and
"capacity is a power of two" constraints. In contrast, the old post-enumeration
shrink calculation was |CeilingLog2(length + length/2)|, which gives higher
results in some cases. (Both calculations also ensured the capacity wasn't too
small.) E.g. if length is 48, the former calculation will give 64, while the
latter will give 128.
Therefore, post-enumeration shrinking will no longer give a
larger-than-necessary capacity some cases. This feels like the right thing to
do in isolation, and making it consistent with HashShift() -- used during table
construction -- is also good.
