Use a dictionary-mode code cache on the map rather than a dual system.

Use a dictionary-mode code cache on the map rather than a dual system.

The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway.

This CL additionally deletes some dead IC code.

BUG=

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

[Toon Verwaest, 2016-03-31 13:46:40]

verwaest@chromium.org changed reviewers:
+ mvstanton@chromium.org, ulan@chromium.org

[Toon Verwaest, 2016-03-31 13:46:41]

mvstanton: ptal
ulan: ptal at heap/

[ulan, 2016-03-31 13:54:50]

heap lgtm

[mvstanton, 2016-04-05 13:10:43]

LGTM!

https://codereview.chromium.org/1846963002/diff/20001/src/builtins.h
File src/builtins.h (left):

https://codereview.chromium.org/1846963002/diff/20001/src/builtins.h#oldcode249
src/builtins.h:249: V(KeyedStoreIC_Initialize, KEYED_STORE_IC, UNINITIALIZED,
kNoExtraICState)   \
Thanks for getting rid of these guys! :)

https://codereview.chromium.org/1846963002/diff/20001/src/heap/incremental-ma...
File src/heap/incremental-marking.cc (left):

https://codereview.chromium.org/1846963002/diff/20001/src/heap/incremental-ma...
src/heap/incremental-marking.cc:930: PolymorphicCodeCache* poly_cache =
heap_->polymorphic_code_cache();
Holy cow, it's good to get rid of this gc-specific stuff for a cache. :/

[Toon Verwaest, 2016-04-06 08:02:24]

The CQ bit was checked by verwaest@chromium.org

[Toon Verwaest, 2016-04-06 08:02:25]

The patchset sent to the CQ was uploaded after l-g-t-m from ulan@chromium.org,
mvstanton@chromium.org
Link to the patchset: https://codereview.chromium.org/1846963002/#ps40001
(title: " ")

[commit-bot: I haz the power, 2016-04-06 08:02:34]

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

[commit-bot: I haz the power, 2016-04-06 08:06:48]

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

[commit-bot: I haz the power, 2016-04-06 08:06:49]

Try jobs failed on following builders:
  v8_linux_dbg_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/3849)
  v8_win_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/5302)

[Toon Verwaest, 2016-04-06 08:18:56]

The CQ bit was checked by verwaest@chromium.org

[Toon Verwaest, 2016-04-06 08:18:56]

The patchset sent to the CQ was uploaded after l-g-t-m from
mvstanton@chromium.org, ulan@chromium.org
Link to the patchset: https://codereview.chromium.org/1846963002/#ps60001
(title: " ")

[commit-bot: I haz the power, 2016-04-06 08:19:04]

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

[commit-bot: I haz the power, 2016-04-06 09:13:27]

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

[commit-bot: I haz the power, 2016-04-06 09:13:28]

Try jobs failed on following builders:
  v8_linux_dbg_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/3854)
  v8_linux_dbg_ng_triggered on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng_triggered/b...)

[ulan, 2016-04-06 09:34:18]

heap lgtm with comment

https://codereview.chromium.org/1846963002/diff/80001/src/heap/heap.cc
File src/heap/heap.cc (right):

https://codereview.chromium.org/1846963002/diff/80001/src/heap/heap.cc#newcod...
src/heap/heap.cc:2181: void FinalizeMap(Heap* heap, Map* map) {
Let's include "PartialMap" in the name to be more descriptive, e.g.
InitializePartialMap, FinalizePartialMap.

[Toon Verwaest, 2016-04-06 09:39:07]

The CQ bit was checked by verwaest@chromium.org

[Toon Verwaest, 2016-04-06 09:39:07]

The patchset sent to the CQ was uploaded after l-g-t-m from
mvstanton@chromium.org, ulan@chromium.org
Link to the patchset: https://codereview.chromium.org/1846963002/#ps100001
(title: "Addressed comment")

[commit-bot: I haz the power, 2016-04-06 09:39:16]

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

[commit-bot: I haz the power, 2016-04-06 10:06:01]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-04-06 10:06:40]

Description was changed from

==========
Use a dictionary-mode code cache on the map rather than a dual system.

The previous code cache system required stubs to be marked with a StubType,
causing them to be inserted either into a fixed array or into a dictionary-mode
code cache. This could cause names to be in both cases, and lookup would just
find the "fast" one first. Given that we clear out the caches on each GC, the
memory overhead shouldn't be too bad. Additionally, the dictionary itself should
just stay linear for small arrays; that's faster anyway.

This CL additionally deletes some dead IC code.

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

to

==========
Use a dictionary-mode code cache on the map rather than a dual system.

The previous code cache system required stubs to be marked with a StubType,
causing them to be inserted either into a fixed array or into a dictionary-mode
code cache. This could cause names to be in both cases, and lookup would just
find the "fast" one first. Given that we clear out the caches on each GC, the
memory overhead shouldn't be too bad. Additionally, the dictionary itself should
just stay linear for small arrays; that's faster anyway.

This CL additionally deletes some dead IC code.

BUG=

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

[commit-bot: I haz the power, 2016-04-06 10:06:44]

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

[Michael Achenbach, 2016-04-07 11:45:34]

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

[Michael Achenbach, 2016-04-07 11:45:35]

Local bisect shows that this CL leads to chromium asan failures:
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium...

It blocks rolling and needs to get fixed/reverted asap. Is there more work
checked in that depends on this CL?

I'll also soon leave repro instructions.

[Michael Achenbach, 2016-04-07 11:52:08]

Repro instructions (I know gyp's deprecated. But it works well enough here
still):
In an updated chromium checkout:
GYP_GENERATORS=ninja GYP_DEFINES='asan=1 clang=1 component=static_library
dcheck_always_on=1 fastbuild=1  lsan=1 target_arch=x64 test_isolation_mode=noop
use_goma=1' gclient sync --revision
src/v8@d2eb555ee11f54ca6b227839831ca5419cf2287e
ninja -C out/Release -j1000 extensions_unittests
testing/xvfb.py out/Release out/Release/extensions_unittests
--brave-new-test-launcher --test-launcher-bot-mode --asan=1
--test-launcher-print-test-stdio=always --test-launcher-batch-limit=1 --lsan=1
--gtest_filter=SerialApiTest.SetControlSignals