Revert of PPC: Type Feedback Vector lives in the closure

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

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

Original issue's description:
> PPC: Type Feedback Vector lives in the closure
>
> Port bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
>
> 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.
>
> R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
>
> Committed: https://crrev.com/753ad25efa4790ea7c80aceecfa223c3436ca36f
> Cr-Commit-Position: refs/heads/master@{#33753}

TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Committed: https://crrev.com/14fa68a30540c19f495e5094e90d5a799d7907d6
Cr-Commit-Position: refs/heads/master@{#33765}

[mvstanton, 2016-02-05 10:44:12]

Created Revert of PPC: Type Feedback Vector lives in the closure

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

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

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

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-02-05 10:45:21]

Description was changed from

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

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

Original issue's description:
> PPC: Type Feedback Vector lives in the closure
> 
> Port bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> 
> 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.
> 
> R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com,
michael_dawson@ca.ibm.com
> BUG=
> 
> Committed: https://crrev.com/753ad25efa4790ea7c80aceecfa223c3436ca36f
> Cr-Commit-Position: refs/heads/master@{#33753}

TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us....
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
==========

to

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

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

Original issue's description:
> PPC: Type Feedback Vector lives in the closure
>
> Port bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
>
> 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.
>
> R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com,
michael_dawson@ca.ibm.com
> BUG=
>
> Committed: https://crrev.com/753ad25efa4790ea7c80aceecfa223c3436ca36f
> Cr-Commit-Position: refs/heads/master@{#33753}

TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us....
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Committed: https://crrev.com/14fa68a30540c19f495e5094e90d5a799d7907d6
Cr-Commit-Position: refs/heads/master@{#33765}
==========

[commit-bot: I haz the power, 2016-02-05 10:45:22]

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