864436 - We're not decommitting memory aggressively enough in B2G's main-process workers

Status: RESOLVED DUPLICATE of bug 829482

(Core :: JavaScript Engine, defect)

Description

[Justin Lebar (not reading bugmail)]

Attachment: Memory report illustrating the problem

B2G's main-process workers have a total of ~3mb of unused-arenas.

I'd originally thought that unused-arenas was wasted memory within arenas, but billm set me straight: unused-arenas are arenas that we /could/ decommit, but that we haven't.

So I think it would be a large, straightforward memory win on B2G to figure out why we're not decommitting these arenas in the workers, and change that.

Comment 1

[Nicholas Nethercote [inactive]]

> I'd originally thought that unused-arenas was wasted memory within arenas,
> but billm set me straight: unused-arenas are arenas that we /could/
> decommit, but that we haven't.

Yes:  unused-gc-things is the wasted memory within arenas.

Arena decommitting happens on a |GC_SHRINK| garbage collection.  js/src/gc/Heap.h has this threshold:

  /*
   * This is the maximum number of arenas we allow in the FreeCommitted state
   * before we trigger a GC_SHRINK to release free arenas to the OS.
   */
  const static uint32_t FreeCommittedArenasThreshold = (32 << 20) / ArenaSize;

The value of that expression on machines with 4 KiB pages is 8,192, which is 32 MiB.  I'm surprised this threshold is so high.  It would be worth trying a much smaller number for B2G.

Comment 2

[Justin Lebar (not reading bugmail)]

Oh, this is the "we don't run shrinking gc's in workers often enough" bug, independently re-discovered.