Flatten the Arrays returned and consumed by the v8::Map API

Flatten the Arrays returned and consumed by the v8::Map API

This will significantly simplify the serialization code, as well
as speeding it up (by triggering only a single allocation instead of O(size)
allocations).

BUG=chromium:478263
LOG=y

Committed: https://crrev.com/353310b7c11fcdf7fa41c64d63109e9a017d90b1
Cr-Commit-Position: refs/heads/master@{#28793}

[adamk, 2015-06-02 22:07:54]

adamk@chromium.org changed reviewers:
+ arv@chromium.org, jochen@chromium.org

[arv (Not doing code reviews), 2015-06-02 22:35:43]

LGTM

https://codereview.chromium.org/1157843006/diff/1/src/collection.js
File src/collection.js (right):

https://codereview.chromium.org/1157843006/diff/1/src/collection.js#newcode488
src/collection.js:488: for (var i = 0; i + 1 < length; i += 2) {
This + 1 is not needed

[adamk, 2015-06-02 22:40:03]

https://codereview.chromium.org/1157843006/diff/1/src/collection.js
File src/collection.js (right):

https://codereview.chromium.org/1157843006/diff/1/src/collection.js#newcode488
src/collection.js:488: for (var i = 0; i + 1 < length; i += 2) {
On 2015/06/02 22:35:43, arv wrote:
> This + 1 is not needed

Tough habit to break from C++, I'd rather leave it in if you don't mind...

[adamk, 2015-06-02 22:56:12]

https://codereview.chromium.org/1157843006/diff/1/src/collection.js
File src/collection.js (right):

https://codereview.chromium.org/1157843006/diff/1/src/collection.js#newcode488
src/collection.js:488: for (var i = 0; i + 1 < length; i += 2) {
On 2015/06/02 22:40:03, adamk wrote:
> On 2015/06/02 22:35:43, arv wrote:
> > This + 1 is not needed
> 
> Tough habit to break from C++, I'd rather leave it in if you don't mind...

Okay, changed my mind, removed the +1 and hardened the API to require an even
length.

[jochen (gone - plz use gerrit), 2015-06-03 10:44:51]

lgtm with question

https://codereview.chromium.org/1157843006/diff/20001/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/1157843006/diff/20001/src/api.cc#newcode6276
src/api.cc:6276: int length = size * 2;
can this overflow?

[adamk, 2015-06-03 15:35:30]

https://codereview.chromium.org/1157843006/diff/20001/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/1157843006/diff/20001/src/api.cc#newcode6276
src/api.cc:6276: int length = size * 2;
On 2015/06/03 10:44:51, jochen wrote:
> can this overflow?

NumberOfElements is stored in a Smi and is guaranteed to be positive, so I don't
think so.

[adamk, 2015-06-03 15:35:35]

The CQ bit was checked by adamk@chromium.org

[adamk, 2015-06-03 15:35:36]

The patchset sent to the CQ was uploaded after l-g-t-m from arv@chromium.org
Link to the patchset: https://codereview.chromium.org/1157843006/#ps20001
(title: "Reject FromArray args with odd lengths")

[commit-bot: I haz the power, 2015-06-03 15:36:05]

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

[commit-bot: I haz the power, 2015-06-03 16:32:57]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-06-03 16:33:06]

Patchset 2 (id:??) landed as
https://crrev.com/353310b7c11fcdf7fa41c64d63109e9a017d90b1
Cr-Commit-Position: refs/heads/master@{#28793}

[Jakob Kummerow, 2015-06-05 15:05:46]

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

[Jakob Kummerow, 2015-06-05 15:05:47]

DBC.

https://codereview.chromium.org/1157843006/diff/20001/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/1157843006/diff/20001/src/api.cc#newcode6276
src/api.cc:6276: int length = size * 2;
On 2015/06/03 15:35:30, adamk wrote:
> On 2015/06/03 10:44:51, jochen wrote:
> > can this overflow?
> 
> NumberOfElements is stored in a Smi and is guaranteed to be positive, so I
don't
> think so.

Uhm... I don't follow this reasoning. On 64-bit platforms, Smis and ints both
have 32 bits including the sign, so a value close to the maximum can absolutely
overflow when you *2 it. Please use CheckedNumerics (from safe_math.h) for
anything that comes even remotely close to the overflow threshold, and is
stability/security sensitive like allocations and indexed accesses are.

[adamk, 2015-06-05 17:42:20]

https://codereview.chromium.org/1157843006/diff/20001/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/1157843006/diff/20001/src/api.cc#newcode6276
src/api.cc:6276: int length = size * 2;
On 2015/06/05 15:05:47, Jakob wrote:
> On 2015/06/03 15:35:30, adamk wrote:
> > On 2015/06/03 10:44:51, jochen wrote:
> > > can this overflow?
> > 
> > NumberOfElements is stored in a Smi and is guaranteed to be positive, so I
> don't
> > think so.
> 
> Uhm... I don't follow this reasoning. On 64-bit platforms, Smis and ints both
> have 32 bits including the sign, so a value close to the maximum can
absolutely
> overflow when you *2 it. Please use CheckedNumerics (from safe_math.h) for
> anything that comes even remotely close to the overflow threshold, and is
> stability/security sensitive like allocations and indexed accesses are.

Sorry, my reason was indeed bogus (I must have been thinking of 31-bit Smis),
but this is safe because OrderedHashTable::kMaxCapacity <
FixedArray::kMaxLength, which itself is already bounded well below int overflow
range.