Deoptimized by soft deoptimize should not affect the opt count

Deoptimized by soft deoptimize should not affect the opt count

[weiliang.lin2, 2013-05-10 09:30:01]

Hi Jakob
The details of pushing this commit is at
https://code.google.com/p/v8/issues/detail?id=2678

Thanks for review

[Jakob Kummerow, 2013-05-13 14:13:01]

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/deoptim...
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.)

[weiliang.lin2, 2013-05-15 02:28:55]

Seem R14658 has already fixed this issue. But it would be better if you could
share your own plan on my commit with me before your commit, especially I am
still working on your comment. Thanks