After some offline discussion here's how I understand the new plan:
* This trigger will be for starting incremental GC only, not for
stop-the-world.
* We try to mark at the same speed as new-space allocation, which (rule of
thumb) is about a third the speed of old-space allocation.
* We estimate the amount of memory that needs marking to be the live objects
from the last GC plus any objects allocated after that.
* Therefore we aim to start incremental marking when the allocated objects
are
3x as big as the remaining distance to the allocation limit.
* We will also start incremental marking when the allocated objects are 3x
as
big as the difference between the max heap size and the committed memory.
* These two rules together mean we expect to finish incremental marking
before
we hit either the allocated object limit or the committed memory limit.
A consequence of this is that sometimes we will start incremental marking
immediately after a GC. For example if we have X=450 C=550 then we aim to
mark
450Mbytes while we allocate 150Mbytes (one third), so we will start
immediately,
since we are only 150M from the 700M and we want to finish before C hits
that
limit.
All this only makes sense if an incremental GC actually compacts at the end.
But I think this is the case now, even if we the incremental GC ends during
an
idle notification?
https://codereview.chromium.org/1038653003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
