Put the type feedback vector in the unoptimized JavaScript frame.

Put the type feedback vector in the unoptimized JavaScript frame.

It's costly to look the vector up in the SharedFunctionInfo. By placing
it in the frame, we save loads. Optimized frames don't have it because
we typically inline several functions in one optimized function, and
the feedback vectors are different.

* DECIDED NOT TO DO THIS FOR NOW *

BUG=

[mvstanton, 2015-02-19 14:30:30]

mvstanton@chromium.org changed reviewers:
+ jarin@chromium.org, titzer@chromium.org

[mvstanton, 2015-02-19 14:30:30]

Hi Ben, hi Jaro, here is the frame change we've discussed. Thanks for the look!
--Michael

[titzer, 2015-02-24 19:32:55]

https://codereview.chromium.org/942513002/diff/20001/src/arm/macro-assembler-...
File src/arm/macro-assembler-arm.h (right):

https://codereview.chromium.org/942513002/diff/20001/src/arm/macro-assembler-...
src/arm/macro-assembler-arm.h:1432: void OSRDropVectorFromStack(int
unoptimized_slot_count, Register scratch0,
I think this method should have a more generic name that suggests what it does.
In particular the name suggests that it only drops something from the stack,
while it in fact copies part of the stack.

Maybe "AdaptUnoptimizeFrameForOsrEntry"?

[Jarin, 2015-02-26 09:22:06]

https://codereview.chromium.org/942513002/diff/20001/src/deoptimizer.cc
File src/deoptimizer.cc (right):

https://codereview.chromium.org/942513002/diff/20001/src/deoptimizer.cc#newco...
src/deoptimizer.cc:2911: CHECK(type_ == StackFrame::JAVA_SCRIPT || type_ ==
StackFrame::OPTIMIZED);
I am quite confused about how we could get StackFrame::OPTIMIZED here as this
method should only be called for output (i.e., unoptimized) frames. The same
goes for ComputeParametersCount and GetExpression.

[mvstanton, 2015-03-20 12:21:09]

Thanks for the comments guys and sorry about the long delay. I needed to
evaluate if this change was really worthwhile from a performance standpoint.
It's helpful enough to go forward.

Thanks for a further look, best,
--Michael

https://codereview.chromium.org/942513002/diff/20001/src/arm/macro-assembler-...
File src/arm/macro-assembler-arm.h (right):

https://codereview.chromium.org/942513002/diff/20001/src/arm/macro-assembler-...
src/arm/macro-assembler-arm.h:1432: void OSRDropVectorFromStack(int
unoptimized_slot_count, Register scratch0,
On 2015/02/24 19:32:55, titzer wrote:
> I think this method should have a more generic name that suggests what it
does.
> In particular the name suggests that it only drops something from the stack,
> while it in fact copies part of the stack.
> 
> Maybe "AdaptUnoptimizeFrameForOsrEntry"?

Good point, and good name. I've changed to AdaptUnoptimizedFrameForOsrEntry.

https://codereview.chromium.org/942513002/diff/20001/src/deoptimizer.cc
File src/deoptimizer.cc (right):

https://codereview.chromium.org/942513002/diff/20001/src/deoptimizer.cc#newco...
src/deoptimizer.cc:2911: CHECK(type_ == StackFrame::JAVA_SCRIPT || type_ ==
StackFrame::OPTIMIZED);
On 2015/02/26 09:22:06, jarin wrote:
> I am quite confused about how we could get StackFrame::OPTIMIZED here as this
> method should only be called for output (i.e., unoptimized) frames. The same
> goes for ComputeParametersCount and GetExpression.

Good point, I've fixed it. That change came out of a kind of dogmatic
refactoring to tolerate StackFrame::OPTIMIZED at downwind locations. 

However, ComputeParametersCount() still needs the check. The reason is that even
though it's nonsensical to examine "expressions" in an optimized frame, it does
happen that we want to know the parameters translation for them. A
FrameDescription is created for the optimized input frame on deoptimization, and
we call ComputeParamersCount() on it.

[mvstanton, 2015-03-25 10:19:58]

ping.

[Jarin, 2015-03-26 06:27:32]

lgtm.