Revert of X87: Type Feedback Vector lives in the closure.

Revert of X87: Type Feedback Vector lives in the closure. (patchset #1 id:1 of https://codereview.chromium.org/1672643002/ )

Reason for revert:
Bugs with chromium api natives, must revert for now.

Original issue's description:
> X87: Type Feedback Vector lives in the closure.
>
>   port bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 (r33741)
>
>   original commit message:
>   (RELAND: the problem before was a missing write barrier for adding the code
>   entry to the new closure. It's been addressed with a new macro instruction
>   and test. The only change to this CL is the addition of two calls to
>   __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
>   We get less "pollution" of type feedback if we have one vector per native
>   context, rather than one for the whole system. This CL moves the vector
>   appropriately.
>
>   We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
>   vector actually lives in the first slot of the literals array (indeed there is
>   great commonality between those arrays, they can be thought of as the same
>   thing). So we make greater effort to ensure there is a valid literals array
>   after compilation.
>
>   This meant, for performance reasons, that we needed to extend
>   FastNewClosureStub to support creating closures with literals. And ultimately,
>   it drove us to move the optimized code map lookup out of FastNewClosureStub
>   and into the compile lazy builtin.
>
>   The heap change is trivial so I TBR Hannes for it...
>   Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
>   And Benedikt reviewed it as well.
>
> BUG=
>
> Committed: https://crrev.com/25bfba9329b93cb8ebefe1446e024005a4227a93
> Cr-Commit-Position: refs/heads/master@{#33759}

TBR=chunyang.dai@intel.com,weiliang.lin@intel.com,zhengxing.li@intel.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Committed: https://crrev.com/0ff456af625e4321a9f3eee4b6db32b5071c1390
Cr-Commit-Position: refs/heads/master@{#33764}

[mvstanton, 2016-02-05 10:43:16]

Created Revert of X87: Type Feedback Vector lives in the closure.

[commit-bot: I haz the power, 2016-02-05 10:43:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1673613002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1673613002/1

[commit-bot: I haz the power, 2016-02-05 10:43:38]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-02-05 10:44:00]

Description was changed from

==========
Revert of X87: Type Feedback Vector lives in the closure. (patchset #1 id:1 of
https://codereview.chromium.org/1672643002/ )

Reason for revert:
Bugs with chromium api natives, must revert for now.

Original issue's description:
> X87: Type Feedback Vector lives in the closure.
> 
>   port bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 (r33741)
> 
>   original commit message:
>   (RELAND: the problem before was a missing write barrier for adding the code
>   entry to the new closure. It's been addressed with a new macro instruction
>   and test. The only change to this CL is the addition of two calls to
>   __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
> 
>   We get less "pollution" of type feedback if we have one vector per native
>   context, rather than one for the whole system. This CL moves the vector
>   appropriately.
> 
>   We rely more heavily on the Optimized Code Map in the SharedFunctionInfo.
The
>   vector actually lives in the first slot of the literals array (indeed there
is
>   great commonality between those arrays, they can be thought of as the same
>   thing). So we make greater effort to ensure there is a valid literals array
>   after compilation.
> 
>   This meant, for performance reasons, that we needed to extend
>   FastNewClosureStub to support creating closures with literals. And
ultimately,
>   it drove us to move the optimized code map lookup out of FastNewClosureStub
>   and into the compile lazy builtin.
> 
>   The heap change is trivial so I TBR Hannes for it...
>   Also, Yang has had a look at the debugger changes already and approved 'em.
So he is TBR style too.
>   And Benedikt reviewed it as well.
> 
> BUG=
> 
> Committed: https://crrev.com/25bfba9329b93cb8ebefe1446e024005a4227a93
> Cr-Commit-Position: refs/heads/master@{#33759}

TBR=chunyang.dai@intel.com,weiliang.lin@intel.com,zhengxing.li@intel.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
==========

to

==========
Revert of X87: Type Feedback Vector lives in the closure. (patchset #1 id:1 of
https://codereview.chromium.org/1672643002/ )

Reason for revert:
Bugs with chromium api natives, must revert for now.

Original issue's description:
> X87: Type Feedback Vector lives in the closure.
>
>   port bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 (r33741)
>
>   original commit message:
>   (RELAND: the problem before was a missing write barrier for adding the code
>   entry to the new closure. It's been addressed with a new macro instruction
>   and test. The only change to this CL is the addition of two calls to
>   __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
>   We get less "pollution" of type feedback if we have one vector per native
>   context, rather than one for the whole system. This CL moves the vector
>   appropriately.
>
>   We rely more heavily on the Optimized Code Map in the SharedFunctionInfo.
The
>   vector actually lives in the first slot of the literals array (indeed there
is
>   great commonality between those arrays, they can be thought of as the same
>   thing). So we make greater effort to ensure there is a valid literals array
>   after compilation.
>
>   This meant, for performance reasons, that we needed to extend
>   FastNewClosureStub to support creating closures with literals. And
ultimately,
>   it drove us to move the optimized code map lookup out of FastNewClosureStub
>   and into the compile lazy builtin.
>
>   The heap change is trivial so I TBR Hannes for it...
>   Also, Yang has had a look at the debugger changes already and approved 'em.
So he is TBR style too.
>   And Benedikt reviewed it as well.
>
> BUG=
>
> Committed: https://crrev.com/25bfba9329b93cb8ebefe1446e024005a4227a93
> Cr-Commit-Position: refs/heads/master@{#33759}

TBR=chunyang.dai@intel.com,weiliang.lin@intel.com,zhengxing.li@intel.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Committed: https://crrev.com/0ff456af625e4321a9f3eee4b6db32b5071c1390
Cr-Commit-Position: refs/heads/master@{#33764}
==========

[commit-bot: I haz the power, 2016-02-05 10:44:01]

Patchset 1 (id:??) landed as
https://crrev.com/0ff456af625e4321a9f3eee4b6db32b5071c1390
Cr-Commit-Position: refs/heads/master@{#33764}

[Weiliang, 2016-02-05 13:24:49]

lgtm