988356 - Investigate making the empty chunk pool per-process

Status: NEW

(Core :: JavaScript: GC, defect)

Description

[Terrence Cole [:terrence]]

Lots of workers means lots of independent unused chunk pools. This could be a significant source of wasted memory. We should find out if this is true in practice.

Comment 1

[Lars T Hansen [:lth]]

PJS GC (bug 933313) introduces its own chunk pool, and it will be a follow-on item for that bug to integrate into a per-process chunk pool.

For PJS GC the requirements are roughly:

- the chunks need to be minimally initialized (no arenas or bitmaps, only the trailer)

- there is a working set of chunks that should be kept around (not decommitted, probably not even
  madvise DONTNEED'ed) once the PJS engine spins up, so that GC and subsequent PJS nursery
  expansion will be very fast.  The memory usage pattern in PJS (within one parallel section that
  does not bail out) is expected to be a slowly growing nursery live set, the nursery may grow
  but will not shrink, but we need more workloads here

- once the PJS engine spins down we should expect it to spin up again fairly soon since
  many parallel operations tend to be done in sequence, so chunks should be retained for some
  time or until we have information about the PJS system going idle

I'm guessing that a general working-set mechanism in the chunk pool coupled with calls to advise the chunk pool about certain events (PJS up, PJS down) will be a nice API.