Before, splice was implemented with a C++ fast path and a
comprehensive JavaScript version.
This impl. is entirely in Torque with a fastpath for SMI,
DOUBLE and OBJECT arrays, and a comprehensive slow path.
The same level of "sparse" array support as given by the
array.js implementation is included.
This reland addresses several issues:
* Removed "sparse" array support from splice.
* Addressed ClusterFuzz issue 876443:
The test and code that uses the fix is in this CL.
The fix in isolation can be seen here:
https://chromium-review.googlesource.com/c/v8/v8/+/1199403
* Removed dead code in elements.cc
BUG=chromium:876443, v8:8131, v8:1956, v8:7221
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1
Reviewed-on: https://chromium-review.googlesource.com/1201783
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55610}
This reverts commit cdaaa31151.
Reason for revert: chromium:876445 chromium:876453 chromium:876443
Original change's description:
> [builtins] Reland Array.prototype.splice() Torque implementation.
>
> Before, splice was implemented with a C++ fast path and a
> comprehensive JavaScript version.
>
> This impl. is entirely in Torque with a fastpath for SMI,
> DOUBLE and OBJECT arrays, and a comprehensive slow path.
> The same level of "sparse" array support as given by the
> array.js implementation is included.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ia7334a30b401988309e9909cfa0069da0bb6fb9f
> Reviewed-on: https://chromium-review.googlesource.com/1169466
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55263}
TBR=mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I5b750a98e671b7284474ffcabc6b4d37a9d1219e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1184741
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55289}
Before, splice was implemented with a C++ fast path and a
comprehensive JavaScript version.
This impl. is entirely in Torque with a fastpath for SMI,
DOUBLE and OBJECT arrays, and a comprehensive slow path.
The same level of "sparse" array support as given by the
array.js implementation is included.
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ia7334a30b401988309e9909cfa0069da0bb6fb9f
Reviewed-on: https://chromium-review.googlesource.com/1169466
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55263}
- remove the Backing-Store specific code from builtins.cc and put it in elements.cc.
- adding tests to improve coverage of the splice method
BUG=
Review URL: https://codereview.chromium.org/1312033003
Cr-Commit-Position: refs/heads/master@{#30410}
doesn't time out on our slowest platforms. It turns out that almost
all the time was spent in Array.prototype.unshift on a non-array with
a length-field holding 40000. We may want to look into that but on
the other hand it is a pretty obscure thing to do so we may not.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1211 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the shell sample don't print the result of executing a script, only
evaluating expressions.
Fixed issue when building samples on Windows using a shared V8
library. Added visibility option on Linux build which makes the
generated library 18% smaller.
Changed build system to accept multiple build modes in one build and
generate seperate objects, libraries and executables for each mode.
Removed deferred negation optimization (a * -b => -(a * b)) since this
visibly changes operand conversion order.
Improved parsing performance by introducing stack guard in preparsing.
Without a stack guard preparsing always bails out with stack overflow.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
