PPC: Type Feedback Vector lives in the closure

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}

[MTBrandyberry, 2016-02-04 21:12:41]

The CQ bit was checked by mbrandy@us.ibm.com to run a CQ dry run

[commit-bot: I haz the power, 2016-02-04 21:12:43]

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

[commit-bot: I haz the power, 2016-02-04 21:32:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-04 21:32:30]

Dry run: This issue passed the CQ dry run.

[michael_dawson, 2016-02-04 21:56:13]

On 2016/02/04 21:32:30, commit-bot: I haz the power wrote:
> Dry run: This issue passed the CQ dry run.

lgtm

[MTBrandyberry, 2016-02-04 22:08:08]

The CQ bit was checked by mbrandy@us.ibm.com

[commit-bot: I haz the power, 2016-02-04 22:08:15]

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

[commit-bot: I haz the power, 2016-02-04 22:09:47]

Committed patchset #1 (id:1)

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

Description was changed from

==========
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=
==========

to

==========
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}
==========

[commit-bot: I haz the power, 2016-02-04 22:10:23]

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

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

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1673623002/ by mvstanton@chromium.org.

The reason for reverting is: issues with chromium api natives, must revert for
now, thanks..