JSArray::shiftCountWithArrayStorage is wrong when an array has holes
authorsbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 15 Oct 2018 19:14:42 +0000 (19:14 +0000)
committersbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 15 Oct 2018 19:14:42 +0000 (19:14 +0000)
commit0a51648f2550e40482ea3cceace32e9a22d95ed0
tree0d231e0e303eda82be1f8f4e78f3892a0d975b4f
parent9080ba3b3e78288fb8f2f9eb0cd634687556813d
JSArray::shiftCountWithArrayStorage is wrong when an array has holes
https://bugs.webkit.org/show_bug.cgi?id=190262
<rdar://problem/44986241>

Reviewed by Mark Lam.

JSTests:

* stress/array-prototype-concat-of-long-spliced-arrays.js:
(test):
* stress/slice-array-storage-with-holes.js: Added.
(main):

Source/JavaScriptCore:

We would take the fast path for shiftCountWithArrayStorage when the array
hasHoles(). However, the code for this was wrong. It'd incorrectly update
ArrayStorage::m_numValuesInVector. Since the hasHoles() for ArrayStorage
path is never taken in JetStream 2, this patch just removes that from
the fast path. Instead, we just fallback to the slow path when hasHoles().
If we find evidence that this matters for real use cases, we can
figure out a way to make the fast path work.

* runtime/JSArray.cpp:
(JSC::JSArray::shiftCountWithArrayStorage):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237129 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JSTests/ChangeLog
JSTests/stress/array-prototype-concat-of-long-spliced-arrays.js
JSTests/stress/slice-array-storage-with-holes.js [new file with mode: 0644]
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/runtime/JSArray.cpp