I don't see what problem this CL is solving. AFAICS,
kInitialMaxFastElementArray
is consistently used as an exclusive upper bound; this change introduces
inconsistency wrt. the use in ArrayConstructorCommon in runtime.cc.
What this patch essentially achieves is to bump the limit from 100,000 to
100,001. I don't see a reason to do that.
If I'm not mistaken, the recently added ASSERT in heap.cc is a little too
strict, we could relax it to use
FixedArray::SizeFor(JSObject::kInitialMaxFastElementArray - 1).
https://codereview.chromium.org/23441080/diff/1/src/code-stubs-hydrogen.cc
File src/code-stubs-hydrogen.cc (right):
https://codereview.chromium.org/23441080/diff/1/src/code-stubs-hydrogen.cc#newcode664
src/code-stubs-hydrogen.cc:664: HInstruction* checked_arg =
Add<HBoundsCheck>(argument, max_alloc_length + 1);
No way!
https://codereview.chromium.org/23441080/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
