Don't do any special normalization if a boilerplate contains function literals.

Don't do any special normalization if a boilerplate contains function literals.

This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.

This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.

BUG=chromium:593008
LOG=n

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

[Toon Verwaest, 2016-03-08 17:19:37]

Description was changed from

==========
Don't do any special normalization if a boilerplate contains function literals.
BUG=
==========

to

==========
Don't do any special normalization if a boilerplate contains function literals.
BUG=chromium:593008
LOG=n
==========

[Toon Verwaest, 2016-03-08 19:39:01]

The CQ bit was checked by verwaest@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-08 19:39:13]

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

[Toon Verwaest, 2016-03-08 19:45:12]

Description was changed from

==========
Don't do any special normalization if a boilerplate contains function literals.
BUG=chromium:593008
LOG=n
==========

to

==========
Don't do any special normalization if a boilerplate contains function literals.

This mechanism was used to ensure that functions ended up as constants on the
map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants
when an object turns prototype. Hence this special custom code isn't necessary
anymore.

This also affects boilerplates that do not become boilerplates. Their functions
will not be constants but fields instead. Calling their methods will slow down.
However, multiple instances of the same boilerplate will stay monomorphic. We'll
have to see what the impact is for such objects, but preliminary benchmarks do
not show this as an important regression.

BUG=chromium:593008
LOG=n
==========

[Toon Verwaest, 2016-03-08 19:45:12]

verwaest@chromium.org changed reviewers:
+ mstarzinger@chromium.org

[Toon Verwaest, 2016-03-08 19:45:31]

ptal

[adamk, 2016-03-08 19:56:50]

DBC: Just looked at the parser stuff because I'd been staring at nearby code a
lot recently.

https://codereview.chromium.org/1772423002/diff/80001/src/parsing/parser-base.h
File src/parsing/parser-base.h (right):

https://codereview.chromium.org/1772423002/diff/80001/src/parsing/parser-base...
src/parsing/parser-base.h:1844: // Mark top-level object literals that contain
function literals and
This is probably the comment that gave me that idea :)

https://codereview.chromium.org/1772423002/diff/80001/src/parsing/parser.h
File src/parsing/parser.h (right):

https://codereview.chromium.org/1772423002/diff/80001/src/parsing/parser.h#ne...
src/parsing/parser.h:412: value->AsFunctionLiteral()->set_pretenure();
Does the pretenuring still make sense? My understanding of this code was that
the pretenuring was for the exact purpose of setting the functions as constant
properties.

[commit-bot: I haz the power, 2016-03-08 20:04:09]

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

[commit-bot: I haz the power, 2016-03-08 20:04:09]

Dry run: This issue passed the CQ dry run.

[Toon Verwaest, 2016-03-08 20:08:50]

The CQ bit was checked by verwaest@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-08 20:08:58]

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

[Toon Verwaest, 2016-03-08 20:09:51]

The CQ bit was checked by verwaest@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-08 20:09:58]

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

[Toon Verwaest, 2016-03-08 20:10:27]

Ok thanks for the hint. Lets try to remove it.

https://codereview.chromium.org/1772423002/diff/80001/src/parsing/parser.h
File src/parsing/parser.h (right):

https://codereview.chromium.org/1772423002/diff/80001/src/parsing/parser.h#ne...
src/parsing/parser.h:412: value->AsFunctionLiteral()->set_pretenure();
On 2016/03/08 19:56:49, adamk wrote:
> Does the pretenuring still make sense? My understanding of this code was that
> the pretenuring was for the exact purpose of setting the functions as constant
> properties.

Probably not. MigrateSlowToFast (for objects used as prototypes) doesn't seem to
care whether the functions are tenured.

[adamk, 2016-03-08 20:14:55]

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

[adamk, 2016-03-08 20:14:56]

lgtm for parser (of course wait for mstarzinger for everything else :)

[Michael Starzinger, 2016-03-08 20:23:41]

LGTM on the compilers. I like it! Just one comment to address. Also I think
there is a typo in the CL description, s/boilerplates/prototypes/ for on of the
occurrences there I think.

https://codereview.chromium.org/1772423002/diff/120001/src/compiler/ast-graph...
File src/compiler/ast-graph-builder.cc (left):

https://codereview.chromium.org/1772423002/diff/120001/src/compiler/ast-graph...
src/compiler/ast-graph-builder.cc:1906: const Operator* op =
javascript()->CallRuntime(Runtime::kToFastProperties);
Now that we no longer emit calls to this runtime method that rely on the
invariant that it cannot deopt, we can remove it from magic list in
Linkage::FrameStateInputCount within the linkage.cc file. I know this is totally
non-obvious, but we haven't found a better solution for this magic list yet.
Thanks!

[Toon Verwaest, 2016-03-08 20:26:12]

Description was changed from

==========
Don't do any special normalization if a boilerplate contains function literals.

This mechanism was used to ensure that functions ended up as constants on the
map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants
when an object turns prototype. Hence this special custom code isn't necessary
anymore.

This also affects boilerplates that do not become boilerplates. Their functions
will not be constants but fields instead. Calling their methods will slow down.
However, multiple instances of the same boilerplate will stay monomorphic. We'll
have to see what the impact is for such objects, but preliminary benchmarks do
not show this as an important regression.

BUG=chromium:593008
LOG=n
==========

to

==========
Don't do any special normalization if a boilerplate contains function literals.

This mechanism was used to ensure that functions ended up as constants on the
map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants
when an object turns prototype. Hence this special custom code isn't necessary
anymore.

This also affects boilerplates that do not become prototypes. Their functions
will not be constants but fields instead. Calling their methods will slow down.
However, multiple instances of the same boilerplate will stay monomorphic. We'll
have to see what the impact is for such objects, but preliminary benchmarks do
not show this as an important regression.

BUG=chromium:593008
LOG=n
==========

[Toon Verwaest, 2016-03-08 20:32:13]

The CQ bit was checked by verwaest@chromium.org

[Toon Verwaest, 2016-03-08 20:32:14]

The patchset sent to the CQ was uploaded after l-g-t-m from
mstarzinger@chromium.org, adamk@chromium.org
Link to the patchset: https://codereview.chromium.org/1772423002/#ps140001
(title: "Remove ToFastProperties from FrameStateInputCount")

[commit-bot: I haz the power, 2016-03-08 20:32:17]

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

[commit-bot: I haz the power, 2016-03-08 20:34:26]

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

[commit-bot: I haz the power, 2016-03-08 20:34:28]

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...)
  v8_linux_arm_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel/builds/14977)

[Toon Verwaest, 2016-03-08 20:42:11]

The CQ bit was checked by verwaest@chromium.org

[commit-bot: I haz the power, 2016-03-08 20:42:17]

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

[commit-bot: I haz the power, 2016-03-08 20:55:46]

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

[commit-bot: I haz the power, 2016-03-08 20:55:47]

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

[Toon Verwaest, 2016-03-08 21:04:37]

The CQ bit was checked by verwaest@chromium.org

[commit-bot: I haz the power, 2016-03-08 21:04:41]

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

[commit-bot: I haz the power, 2016-03-08 21:19:51]

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

[commit-bot: I haz the power, 2016-03-08 21:19:52]

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

[Toon Verwaest, 2016-03-08 21:37:55]

The CQ bit was checked by verwaest@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-08 21:37:57]

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

[Toon Verwaest, 2016-03-08 21:49:08]

The CQ bit was checked by verwaest@chromium.org

[Toon Verwaest, 2016-03-08 21:49:08]

The patchset sent to the CQ was uploaded after l-g-t-m from
mstarzinger@chromium.org, adamk@chromium.org
Link to the patchset: https://codereview.chromium.org/1772423002/#ps160001
(title: "mark osr-one/osr-two as skip on ignition/arm")

[commit-bot: I haz the power, 2016-03-08 21:49:17]

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

[commit-bot: I haz the power, 2016-03-08 22:13:33]

Description was changed from

==========
Don't do any special normalization if a boilerplate contains function literals.

This mechanism was used to ensure that functions ended up as constants on the
map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants
when an object turns prototype. Hence this special custom code isn't necessary
anymore.

This also affects boilerplates that do not become prototypes. Their functions
will not be constants but fields instead. Calling their methods will slow down.
However, multiple instances of the same boilerplate will stay monomorphic. We'll
have to see what the impact is for such objects, but preliminary benchmarks do
not show this as an important regression.

BUG=chromium:593008
LOG=n
==========

to

==========
Don't do any special normalization if a boilerplate contains function literals.

This mechanism was used to ensure that functions ended up as constants on the
map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants
when an object turns prototype. Hence this special custom code isn't necessary
anymore.

This also affects boilerplates that do not become prototypes. Their functions
will not be constants but fields instead. Calling their methods will slow down.
However, multiple instances of the same boilerplate will stay monomorphic. We'll
have to see what the impact is for such objects, but preliminary benchmarks do
not show this as an important regression.

BUG=chromium:593008
LOG=n
==========

[commit-bot: I haz the power, 2016-03-08 22:13:34]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-03-08 22:14:02]

Description was changed from

==========
Don't do any special normalization if a boilerplate contains function literals.

This mechanism was used to ensure that functions ended up as constants on the
map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants
when an object turns prototype. Hence this special custom code isn't necessary
anymore.

This also affects boilerplates that do not become prototypes. Their functions
will not be constants but fields instead. Calling their methods will slow down.
However, multiple instances of the same boilerplate will stay monomorphic. We'll
have to see what the impact is for such objects, but preliminary benchmarks do
not show this as an important regression.

BUG=chromium:593008
LOG=n
==========

to

==========
Don't do any special normalization if a boilerplate contains function literals.

This mechanism was used to ensure that functions ended up as constants on the
map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants
when an object turns prototype. Hence this special custom code isn't necessary
anymore.

This also affects boilerplates that do not become prototypes. Their functions
will not be constants but fields instead. Calling their methods will slow down.
However, multiple instances of the same boilerplate will stay monomorphic. We'll
have to see what the impact is for such objects, but preliminary benchmarks do
not show this as an important regression.

BUG=chromium:593008
LOG=n

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

[commit-bot: I haz the power, 2016-03-08 22:14:03]

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