Reland of Type Feedback Vector lives in the closure

Reland of Type Feedback Vector lives in the closure

(Fixed a bug found by nosnap builds.)

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

TBR=hpayer@chromium.org
BUG=

Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
Cr-Commit-Position: refs/heads/master@{#33548}

[mvstanton, 2016-01-27 11:44:35]

Description was changed from

==========
Reland of Type Feedback Vector lives in the closure

Fixed a bug found by nosnap builds.

BUG=
==========

to

==========
Reland of Type Feedback Vector lives in the closure

(Fixed a bug found by nosnap builds.)

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

TBR=hpayer@chromium.org
BUG=
==========

[mvstanton, 2016-01-27 11:44:35]

mvstanton@chromium.org changed reviewers:
+ bmeurer@chromium.org

[mvstanton, 2016-01-27 11:51:11]

Hi Benedikt,
Here is the patch again.
Patchset 1 you already reviewed.
Patchset 2 has the fix for the nosnap issue.
Thanks for the look!
--Mike

[Yang, 2016-01-27 12:32:24]

yangguo@chromium.org changed reviewers:
+ yangguo@chromium.org

[Yang, 2016-01-27 12:32:24]

src/debug lgtm.

[Benedikt Meurer, 2016-01-27 12:51:04]

lgtm

[mvstanton, 2016-01-27 12:51:19]

The CQ bit was checked by mvstanton@chromium.org

[commit-bot: I haz the power, 2016-01-27 12:51:23]

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

[commit-bot: I haz the power, 2016-01-27 12:53:18]

Description was changed from

==========
Reland of Type Feedback Vector lives in the closure

(Fixed a bug found by nosnap builds.)

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

TBR=hpayer@chromium.org
BUG=
==========

to

==========
Reland of Type Feedback Vector lives in the closure

(Fixed a bug found by nosnap builds.)

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

TBR=hpayer@chromium.org
BUG=
==========

[commit-bot: I haz the power, 2016-01-27 12:53:18]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-01-27 12:53:48]

Description was changed from

==========
Reland of Type Feedback Vector lives in the closure

(Fixed a bug found by nosnap builds.)

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

TBR=hpayer@chromium.org
BUG=
==========

to

==========
Reland of Type Feedback Vector lives in the closure

(Fixed a bug found by nosnap builds.)

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

TBR=hpayer@chromium.org
BUG=

Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
Cr-Commit-Position: refs/heads/master@{#33548}
==========

[commit-bot: I haz the power, 2016-01-27 12:53:51]

Patchset 2 (id:??) landed as
https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
Cr-Commit-Position: refs/heads/master@{#33548}

[mvstanton, 2016-01-27 15:03:42]

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

The reason for reverting is: Bug: failing to use write barrier when writing code
entry into closure..