Type Feedback Vector lives in the closure

Type Feedback Vector lives in the closure

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/a5200f7ed4d11c6b882fa667da7a1864226544b4
Cr-Commit-Position: refs/heads/master@{#33518}

[mvstanton, 2016-01-12 14:19:36]

Patchset #4 (id:60001) has been deleted

[mvstanton, 2016-01-13 12:09:20]

Patchset #6 (id:120001) has been deleted

[mvstanton, 2016-01-15 10:40:27]

Description was changed from

==========
FastNewClosureStub can be used if the function has literals.

This is part 1 of 2 parts, moving the type feedback vector to the
closure.

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

to

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

Now it all hangs together rather nicely.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

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

[mvstanton, 2016-01-15 10:40:27]

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

[mvstanton, 2016-01-15 10:40:59]

Hi Benedikt, here is the vector closure CL that has been such fun :). Thanks!
--Mike

[mvstanton, 2016-01-15 10:42:49]

And Friends-of-MIPs, could you guys look into the MIPS and MIPS64 port? Thanks
for the help!
--Mike

[akos.palfi.imgtec, 2016-01-15 11:10:19]

On 2016/01/15 10:42:49, mvstanton wrote:
> And Friends-of-MIPs, could you guys look into the MIPS and MIPS64 port? Thanks
> for the help!
> --Mike

We are on it! :)

[mvstanton, 2016-01-15 11:32:16]

Description was changed from

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

Now it all hangs together rather nicely.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

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

to

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

[Benedikt Meurer, 2016-01-15 11:36:43]

Nice. LGTM with comment.

https://codereview.chromium.org/1563213002/diff/140001/src/crankshaft/hydroge...
File src/crankshaft/hydrogen.cc (right):

https://codereview.chromium.org/1563213002/diff/140001/src/crankshaft/hydroge...
src/crankshaft/hydrogen.cc:8436: JSFunction::EnsureLiterals(target);
Can we check this in the heap verifier?

[akos.palfi.imgtec, 2016-01-15 13:15:55]

akos.palfi@imgtec.com changed reviewers:
+ akos.palfi@imgtec.com

[akos.palfi.imgtec, 2016-01-15 13:15:55]

Hi Michael,

Please find the mips ports here: https://codereview.chromium.org/1587073009/

[Benedikt Meurer, 2016-01-18 06:17:41]

Description was changed from

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

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

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-18 16:02:31]

The CQ bit was checked by mvstanton@chromium.org

[mvstanton, 2016-01-18 16:02:32]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1563213002/#ps180001
(title: "REBASE and ports.")

[commit-bot: I haz the power, 2016-01-18 16:02:47]

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

[commit-bot: I haz the power, 2016-01-18 16:39:21]

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

[commit-bot: I haz the power, 2016-01-18 16:39:22]

Try jobs failed on following builders:
  v8_linux_arm64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel/builds/1...)

[mvstanton, 2016-01-20 14:07:06]

The CQ bit was checked by mvstanton@chromium.org

[mvstanton, 2016-01-20 14:07:11]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1563213002/#ps200001
(title: "Failing ignition test disabled.")

[commit-bot: I haz the power, 2016-01-20 14:07:14]

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

[commit-bot: I haz the power, 2016-01-20 14:40:10]

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

[commit-bot: I haz the power, 2016-01-20 14:40:10]

Try jobs failed on following builders:
  v8_linux_arm64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel/builds/1...)

[mvstanton, 2016-01-26 12:32:45]

The CQ bit was checked by mvstanton@chromium.org

[mvstanton, 2016-01-26 12:32:46]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1563213002/#ps240001
(title: "REBASE (again).")

[commit-bot: I haz the power, 2016-01-26 12:32:56]

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

[commit-bot: I haz the power, 2016-01-26 12:44:58]

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

[commit-bot: I haz the power, 2016-01-26 12:44:59]

Try jobs failed on following builders:
  v8_linux_arm64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel/builds/1...)

[mvstanton, 2016-01-26 14:18:11]

The CQ bit was checked by mvstanton@chromium.org

[mvstanton, 2016-01-26 14:18:11]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1563213002/#ps260001
(title: "Exclude an ignition test.")

[commit-bot: I haz the power, 2016-01-26 14:18:22]

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

[commit-bot: I haz the power, 2016-01-26 14:20:16]

Description was changed from

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

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

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

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-26 14:20:17]

Committed patchset #12 (id:260001)

[commit-bot: I haz the power, 2016-01-26 14:21:15]

Description was changed from

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

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

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

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/a5200f7ed4d11c6b882fa667da7a1864226544b4
Cr-Commit-Position: refs/heads/master@{#33518}
==========

[commit-bot: I haz the power, 2016-01-26 14:21:16]

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

[mvstanton, 2016-01-26 15:00:53]

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

The reason for reverting is: FAilure on win32 bot, need to investigate webkit
failures..

[Michael Achenbach, 2016-01-26 15:02:33]

Also seem to introduce this flake:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20-%...

[Michael Achenbach, 2016-01-26 15:03:08]

On 2016/01/26 15:02:33, Michael Achenbach wrote:
> Also seem to introduce this flake:
>
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20-%...

And fails here:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap