The reason for this soft deopt approach is that there is no way to know in
the
common case if the receiver of .call is the array slice function because
it's a
context lookup. For example CoffeeScript and jQuery save a reference to
slice
instad of using `Array.prototype.slice.call` or `[].slice.call`.
From the detected argument patterns it's a pretty safe assumption that in
reasonable code it will be reference to slice, but if it's not, it shouldn't
just go into a deoptimization loop, should it?
Only doing this optimization when we know the receiver of .call is the array
slice function (e.g. in Array.prototype.slice.call and [].slice.call) could
be
done very cleanly and within the existing framework yes, but it would have a
much smaller impact. In fact the feature request mentions CoffeeScript which
wouldn't benefit.
So we could:
1. Settle for a small impact but not create any new frameworks
2. Create a framework for risky but reasonable optimistic assumptions that
cannot be validated until the optimized code actually runs and then marking
such
functions if these assumptions fail to avoid going into a deopt loop. The CL
currently implements this.
https://codereview.chromium.org/327173002/
--
--
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/d/optout.
