Keep prototype maps in dictionary mode until ICs see them

Keep prototype maps in dictionary mode until ICs see them

Adding properties to prototypes is faster when we don't force their
maps into fast mode yet. Once a prototype shows up in the IC system,
its setup phase is likely over, and it makes sense to transition it
to fast properties.
This patch speeds up the microbenchmark in the bug by 20x.
Octane-Typescript sees a 3% improvement.

BUG=chromium:607010
Committed: https://crrev.com/be0494ba5bfdc8f7b225372ed7990a06dca7ad46
Cr-Commit-Position: refs/heads/master@{#36828}

[Jakob Kummerow, 2016-06-07 14:36:36]

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

[Jakob Kummerow, 2016-06-07 14:36:37]

PTAL.

https://codereview.chromium.org/2036493006/diff/20001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2036493006/diff/20001/src/objects.h#newcode2173
src/objects.h:2173: static void MakePrototypesFast(Handle<Object> receiver, bool
include_receiver,
Would "MakePrototypesGreatAgain" be a better name? ;-)

[Toon Verwaest, 2016-06-07 14:48:07]

Looking good. Seems simple enough. A few minor comments.

https://codereview.chromium.org/2036493006/diff/20001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/2036493006/diff/20001/src/objects.cc#newcode1...
src/objects.cc:12063: GetOrCreatePrototypeInfo(map,
isolate)->set_should_be_fast_map(value);
If the bool is false, should we really allocate a PrototypeInfo?

https://codereview.chromium.org/2036493006/diff/20001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2036493006/diff/20001/src/objects.h#newcode6341
src/objects.h:6341: static const int kShouldBeFastBit = 0;
What about using BitField?

https://codereview.chromium.org/2036493006/diff/20001/src/runtime/runtime-for...
File src/runtime/runtime-forin.cc (right):

https://codereview.chromium.org/2036493006/diff/20001/src/runtime/runtime-for...
src/runtime/runtime-forin.cc:113: JSObject::MakePrototypesFast(receiver, true /*
include_receiver */, isolate);
Given all these /* include_receiver */, what about just adding an enum?

[Jakob Kummerow, 2016-06-08 12:19:00]

https://codereview.chromium.org/2036493006/diff/20001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/2036493006/diff/20001/src/objects.cc#newcode1...
src/objects.cc:12063: GetOrCreatePrototypeInfo(map,
isolate)->set_should_be_fast_map(value);
On 2016/06/07 14:48:06, Toon Verwaest wrote:
> If the bool is false, should we really allocate a PrototypeInfo?

Good point (although it never happens currently). Done.

https://codereview.chromium.org/2036493006/diff/20001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2036493006/diff/20001/src/objects.h#newcode6341
src/objects.h:6341: static const int kShouldBeFastBit = 0;
On 2016/06/07 14:48:06, Toon Verwaest wrote:
> What about using BitField?

As discussed offline: BitFields are more verbose, the BOOL_ACCESSORS macro
nicely does the job as long as we only need single-bit flags.

https://codereview.chromium.org/2036493006/diff/20001/src/runtime/runtime-for...
File src/runtime/runtime-forin.cc (right):

https://codereview.chromium.org/2036493006/diff/20001/src/runtime/runtime-for...
src/runtime/runtime-forin.cc:113: JSObject::MakePrototypesFast(receiver, true /*
include_receiver */, isolate);
On 2016/06/07 14:48:06, Toon Verwaest wrote:
> Given all these /* include_receiver */, what about just adding an enum?

Done.

[Toon Verwaest, 2016-06-08 12:21:54]

cool, lgtm

[Jakob Kummerow, 2016-06-08 12:26:06]

The CQ bit was checked by jkummerow@chromium.org

[commit-bot: I haz the power, 2016-06-08 12:26:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036493006/40001

[commit-bot: I haz the power, 2016-06-08 12:43:51]

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

[commit-bot: I haz the power, 2016-06-08 12:43:52]

Try jobs failed on following builders:
  v8_linux64_avx2_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux64_avx2_rel_ng_triggered on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...)

[Jakob Kummerow, 2016-06-08 14:16:38]

The CQ bit was checked by jkummerow@chromium.org

[Jakob Kummerow, 2016-06-08 14:16:38]

The patchset sent to the CQ was uploaded after l-g-t-m from
verwaest@chromium.org
Link to the patchset: https://codereview.chromium.org/2036493006/#ps80001
(title: "make ignition tests happy")

[commit-bot: I haz the power, 2016-06-08 14:16:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036493006/80001

[commit-bot: I haz the power, 2016-06-08 14:43:30]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-06-08 14:43:56]

Description was changed from

==========
Keep prototype maps in dictionary mode until ICs see them

Adding properties to prototypes is faster when we don't force their
maps into fast mode yet. Once a prototype shows up in the IC system,
its setup phase is likely over, and it makes sense to transition it
to fast properties.
This patch speeds up the microbenchmark in the bug by 20x.
Octane-Typescript sees a 3% improvement.

BUG=chromium:607010
==========

to

==========
Keep prototype maps in dictionary mode until ICs see them

Adding properties to prototypes is faster when we don't force their
maps into fast mode yet. Once a prototype shows up in the IC system,
its setup phase is likely over, and it makes sense to transition it
to fast properties.
This patch speeds up the microbenchmark in the bug by 20x.
Octane-Typescript sees a 3% improvement.

BUG=chromium:607010

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

[commit-bot: I haz the power, 2016-06-08 14:43:57]

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