1449600 - (MinGCMem) [meta] Investigate reducing minimum GC memory

Status: NEW

(Core :: JavaScript: GC, enhancement, P3)

Description

[Ted Campbell [:tcampbell]]

We currently use a 1MB minimum Nursery and a 1MB granularity for GC Chunks. In a potential process-per-origin world, we may find a number of tiny origins that have less than 1MB of JS.

With respect to nursery, there are a few options we can play with:
  - Avoid creating nursery (at a perf impact) for some per-origin processes (what is heuristic?)
  - Use reserved+decommitted pages for nursery and grow as needed. Occasionally shrinking it back down.
  - Use a smaller nursery chunk size

With respect to tenured chunks:
  - Use decommitted pages (maybe only when heap is smaller than a certain size?)

Comment 1

[Paul Bone [:pbone]]

(In reply to Ted Campbell [:tcampbell] from comment #0)
> We currently use a 1MB minimum Nursery and a 1MB granularity for GC Chunks.
> In a potential process-per-origin world, we may find a number of tiny
> origins that have less than 1MB of JS.
> 
> With respect to nursery, there are a few options we can play with:
>   - Avoid creating nursery (at a perf impact) for some per-origin processes
> (what is heuristic?)

This might actually increase memory usage if we don't connect the tenured heap frequently to remove memory that becomes garbage almost straight away.

A better idea might be on small JS runtimes after each JS event (onClick etc) we perform a nursery collection (we should do this anyway if we don't already) and freeing all the chunks for the entire nursery.  We may find that if memory is not allocated for some time not having empty nursery pages saves some memory.

>   - Use reserved+decommitted pages for nursery and grow as needed.
> Occasionally shrinking it back down.

This should be combined with Bug 1433007, which proposes using the existing 1MB chunk sizes but doing nursery collection much sooner by doing this we could use a chunk that is mostly decommitted and only touch the first few pages.

Comment 2

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Looks like we have a resonable opportunity to reduce memory here. How do I get it onto your todo list?

Comment 3

[Paul Bone [:pbone]]

Hi Anthony,  (Oh that's who Kentuckyfriedtakahe is!)

This is "next" in my TODO list.  I'm trying to finish up my last major change and then I can work on this.  THe good news is that I think this is fairly low-risk.

Comment 4

[Eric Rahm [:erahm]]

Paul, does it look like you'll have time to look at this again?

Comment 5

[Paul Bone [:pbone]]

I'm working on Bug 1433007 (a dependency) right now, it's the most obvious way we can reduce minimum nursery memory usage.

Some other things that might affect memory usage that I'm working on:
 * Might reduce nursery size more generally: 1492711
 * May create an upper bound on nursery size in some situations: 1397549

Regarding minimum memory usage, we should also consider using a smaller chunk size, this will create more memory usage over all (more chunk headers per byte/object).  But should help with overheads when very few objects of a particular kind are allocated.  NI sfink so we can discuss this idea.

There's likely other ideas to investigate too.

Comment 6

[Steve Fink [:sfink] [:s:]]

(In reply to Paul Bone [:pbone] from comment #5)

Regarding minimum memory usage, we should also consider using a smaller
chunk size, this will create more memory usage over all (more chunk headers
per byte/object). But should help with overheads when very few objects of a
particular kind are allocated. NI sfink so we can discuss this idea.

Maybe I'm misunderstanding, but I don't see how reducing the chunk size would help? Chunks contain many AllocKinds already; it's the Arenas that are homogeneous in AllocKinds. I guess we could drop the arena size below 4KB, but at the smallest size (16 bytes) we already only fit 256 cells in an arena. 32 bytes is 128 cells. That's some amount of space loss to fragmentation, but it doesn't feel like all that much?

Comment 7

[Paul Bone [:pbone]]

(In reply to Steve Fink [:sfink] [:s:] from comment #6)

(In reply to Paul Bone [:pbone] from comment #5)

Regarding minimum memory usage, we should also consider using a smaller
chunk size, this will create more memory usage over all (more chunk headers
per byte/object). But should help with overheads when very few objects of a
particular kind are allocated. NI sfink so we can discuss this idea.

Maybe I'm misunderstanding, but I don't see how reducing the chunk size would help? Chunks contain many AllocKinds already; it's the Arenas that are homogeneous in AllocKinds. I guess we could drop the arena size below 4KB, but at the smallest size (16 bytes) we already only fit 256 cells in an arena. 32 bytes is 128 cells. That's some amount of space loss to fragmentation, but it doesn't feel like all that much?

I don't know what I was thinking wrt chunks. I knew that it's the arenas that have different alloc kinds so I have no idea what September-me was thinking. Maybe I was thinking of partially used chunks, but we could address that with how we allocate new areas from chunks (if we don't already).

Regarding Arenas, I would not want to make them any smaller than 4K. I agree 4K is already quite small.

Comment 8

[Paul Bone [:pbone]]

There are now a few different ideas for reducing memory used by the GC, so I've made this a meta bug.

We should also check this meta bug once we know how to track which processes have all their tabs in the background and can therefore switch to some settings that conserve memory further.