Great analysis of the performance issues, and impressive speedups!
Disregarding soft deopts for the purpose of giving up after
FLAG_max_opt_count
optimizations sounds like a good idea. However, I'm a bit concerned that
doing
so might introduce unfortunate corner cases where ICs keep getting cleared
for
some reason and we'll waste significant time with countless reoptimizations
after soft deopts that never go away (due to the ongoing IC clearing). Can
you
convince me that that's not an issue?
Also, I don't think it's the right approach to have this crucial bit of
behavior
in platform-specific generated code. Bookkeeping like this belongs in some
platform-independent part of the runtime; in this particular case somewhere
around
https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/deoptimizer.cc#547
where we're doing bookkeeping anyway seems like a good candidate. We'll
have to
find a way to make the Deoptimizer aware of the deopt reason.
(As a side note, platform specific changes need an ARM port before we can
land
them; but of course it's perfectly fine to discuss the general direction of
a
patch before doing all the platform ports.)
https://codereview.chromium.org/14791014/
--
--
v8-dev mailing list
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
