Make JSProxies always be in slow mode

Make JSProxies always be in slow mode

That way, we don't have to implement the fast <-> slow migration logic,
and we don't allocate in-object properties anyways

BUG=chromium:571365
R=verwaest@chromium.org,neis@chromium.org
LOG=n

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

[Toon Verwaest, 2016-01-14 09:50:37]

LGTM. Just make sure the empty dictionary isn't mutated when a property is
added. I especially like the idea of creating a copy of the lines of code
relevant to get/set/has/delete for slow-mode objects; guaranteeing that only
private symbols are used as keys.

[jochen (gone - plz use gerrit), 2016-01-15 09:12:37]

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

[jochen (gone - plz use gerrit), 2016-01-15 09:12:37]

+yangguo to double check my dictionary magic

[Yang, 2016-01-15 10:19:14]

LGTM, but looking at the existing code made me sad.

https://codereview.chromium.org/1582773003/diff/20001/src/heap/heap.cc
File src/heap/heap.cc (right):

https://codereview.chromium.org/1582773003/diff/20001/src/heap/heap.cc#newcod...
src/heap/heap.cc:2756: NameDictionary::New(isolate(), 0, TENURED);
This actually allocates the underlying HashTable with a capacity of 4, since the
default capacity option is USE_DEFAULT_MINIMUM_CAPACITY. This seems fine since
you set the number of deleted elements to the capacity, triggering new
allocation on adding, but you can still set elements via ValueAtPut? Then it
would totally screw up things because once overwritten, IsDeleted may return
false, and NumberOfEnumElements also returns not 0.

That being said... whoever uses ValueAtPut without ensuring capacity upfront is
set up for failure anyways. I'm just saying that all of this is kind of brittle.

Maybe we could add assertions to ValueAtPut to make sure they do not write out
of bound, but then it occurred to me that calling it also screws with our
tracking of deleted items.

:(

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

https://codereview.chromium.org/1582773003/diff/20001/src/objects.cc#newcode1...
src/objects.cc:18090: int capacity = DerivedHashTable::Capacity();
Could we factor out this criteria of reallocation? This is clearly a duplicate
of DerivedHashTable::EnsureCapacity.

[jochen (gone - plz use gerrit), 2016-01-15 10:51:57]

The CQ bit was checked by jochen@chromium.org

[jochen (gone - plz use gerrit), 2016-01-15 10:51:57]

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

[commit-bot: I haz the power, 2016-01-15 10:52:08]

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

[commit-bot: I haz the power, 2016-01-15 10:57:31]

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

[commit-bot: I haz the power, 2016-01-15 10:57:31]

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

[jochen (gone - plz use gerrit), 2016-01-15 12:00:08]

The CQ bit was checked by jochen@chromium.org

[jochen (gone - plz use gerrit), 2016-01-15 12:00:08]

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

[commit-bot: I haz the power, 2016-01-15 12:00:15]

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

[commit-bot: I haz the power, 2016-01-15 13:02:55]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-01-15 13:03:20]

Description was changed from

==========
Make JSProxies always be in slow mode

That way, we don't have to implement the fast <-> slow migration logic,
and we don't allocate in-object properties anyways

BUG=chromium:571365
R=verwaest@chromium.org,neis@chromium.org
LOG=n
==========

to

==========
Make JSProxies always be in slow mode

That way, we don't have to implement the fast <-> slow migration logic,
and we don't allocate in-object properties anyways

BUG=chromium:571365
R=verwaest@chromium.org,neis@chromium.org
LOG=n

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

[commit-bot: I haz the power, 2016-01-15 13:03:20]

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