I think we'll take another look at it Monday.
One idea is to add up the unutilized idle times and use those to measure how
much time has gone. That way any test that controls the idle notifications
is
still deterministic on varying devices and system loads.
I'd like to get rid of the idea of idle rounds. Doing 7 GCs is too much
from a
battery point of view. Really the only reason to do more than one is to
clear
out the data that ages slowly, but that is totally artificial, we can
lightening-age it if we want.
The other reason to do multiple GCs is if we wanted to compact more memory,
but
had to limit the amount of compaction due to pause time worries.
So suggestion:
* If idle GCs are not blocked, we do idle GCs until there is no more
compaction
work to be done. Often this means just one idle GC.
* We now ignore idle notifications: the only thing we do is count up the
milliseconds we were given, but decided not to use. This simulates GC
rounds
2-6, but uses no power.
* When we have counted up enough idle notifications, we do a fast-ageing GC
that
deletes as much as possible as if everything had aged. This will have the
same
effect as the 5 GCs we skipped (esp. when the phantom handles are used
throughout the API)
* After that we block idle GCs until a certain amount of memory has been
allocated (30% growth of old space, or old space gets 50% closer to the
limit)
or until a context is disposed. We back off the non-idle GC triggers so
they
trigger later than this.
Related: https://codereview.chromium.org/677043002/
https://codereview.chromium.org/1023153002/
--
--
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.
