Ted Campbell [:tcampbell] Reporter
	Description • 6 years ago

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?)

	Paul Bone [:pbone]
	Comment 1 • 6 years ago

(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.

	Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)
	Comment 2 • 6 years ago

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

	Paul Bone [:pbone]
	Comment 3 • 6 years ago

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.

	Eric Rahm [:erahm]
	Comment 4 • 6 years ago

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

	Paul Bone [:pbone]
	Comment 5 • 6 years ago

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.