Open Bug 988356 Opened 6 years ago Updated 4 years ago

Investigate making the empty chunk pool per-process

Categories

(Core :: JavaScript: GC, defect)

defect
Not set

Tracking

()

People

(Reporter: terrence, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [MemShrink:P2])

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.
Whiteboard: [MemShrink]
Blocks: 941783
Whiteboard: [MemShrink] → [MemShrink:P2]
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.
Depends on: 933313
Blocks: 1115139
Blocks: 1270554
Depends on: 1272449
You need to log in before you can comment on or make changes to this bug.