Currently we still don't flush optimized code, so adding the bit to
OPTIMIZED_FUNCTION as well wouldn't make any difference right now. That
being
said, flushing of optimized code has been on our agenda for ages, and we
shouldn't build anything into the systems that makes flushing of optimized
code
less powerful compared to unoptimized code.
Ok, I added support for OPTIMIZED_FUNCTION too.
The reason I suggested a counter is an intuition about aging of code. If a
function has been executed zero times, then it should be thrown away
immediately
during GC. If it has been executed only once, it probably was global
initialization code and probably should be thrown away quickly, too. If a
function has been executed 2 or more times, it probably is something that
is
worth keeping around since it might be executed again.
I don't know how you would maintain this counter though. You would need to
set
the initial prologue to jump to a stub which increments this counter then
patches the prologue to be young again (that gets you from 0->1
invocation), but
then how would you know that the execution count had gone above 1 unless the
prologue has code to always increment this counter even when the code is
young?
This would seem like a pretty big performance hit, even if we disabled this
counter after the first GC subsequent to the code being generated.
Is there any reason to not have this optimization always on, not just for
low-memory devices? If there is no regression, it seems like I would
prefer
having a unified policy, it reduces the testing matrix and makes tracking
down
problems easier.
It was on unconditionally in a previous patch-set, but Hannes wanted to be
a bit
more conservative and only do it on low memory devices. There didn't seem
to be
a performance regression when we tested it though, so I'm happy to turn it
on
unconditionally if you are OK with that.
https://codereview.chromium.org/23480031/
--
--
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/groups/opt_out.
