Move (Shared)Array.prototype.slice to C++
Categories
(Core :: JavaScript: Standard Library, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox140 | --- | fixed |
People
(Reporter: anba, Assigned: anba)
References
Details
Attachments
(8 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Moving (Shared)Array.prototype.slice to C++ avoids adding a bunch of self-hosting intrinsics and helps a bit for implementing the "Immutable ArrayBuffer" proposal (bug 1952253). When using fuses for the species constructor, there's additional a performance improvement when copying small ArrayBuffers using inline storage.
| Assignee | ||
Comment 1•5 months ago
|
||
Add ToIntegerIndex in preparation for the next part.
ToIntegerIndex needs to be instantiated for size_t and uint64_t. It's not
valid add explicit instantiations for both size_t and uint64_t, because
size_t is uint64_t on 64-bit platforms and it's invalid to have duplicate
template instantiations. Instead instantiate uint32_t and uint64_t to handle
32- and 64-bit targets.
| Assignee | ||
Comment 2•5 months ago
|
||
Re-implement ArrayBuffer.prototype.slice in C++, because the self-hosted
implementation needs to call into C++ anyway for copying the bytes. And it
makes things easier for implementing ArrayBuffer.prototype.sliceToImmutable
from the "Immutable ArrayBuffer" proposal.
Part 3 will remove the self-hosted implementation. And part 8 will add a fast
path when the species constructor is the built-in ArrayBuffer constructor.
| Assignee | ||
Comment 3•5 months ago
|
||
Remove the self-hosted function and all supporting intrinsics.
| Assignee | ||
Comment 4•5 months ago
|
||
Noticed in part 3 that there are more no longer used built-in object kinds.
| Assignee | ||
Comment 5•5 months ago
|
||
Also move the SharedArrayBuffer version to C++ to match how ArrayBuffer is
now implemented.
SharedArrayBufferObject::copyData no longer uses handles to avoid unnecessary
rooting for unwrappedResult in SharedArrayBufferObject::sliceImpl.
| Assignee | ||
Comment 6•5 months ago
|
||
| Assignee | ||
Comment 7•5 months ago
|
||
Used in the next part to optimise slice for the common case when the species
constructor is the built-in (Shared)ArrayBuffer constructor.
| Assignee | ||
Comment 8•5 months ago
|
||
This gives a noticeable speed-up in µ-benchmarks when constructing ArrayBuffer
objects with inline storage. SharedArrayBuffer objects don't benefit that much,
but it probably doesn't hurt to align SharedArrayBuffer with ArrayBuffer.
Updated•5 months ago
|
Comment 10•5 months ago
|
||
Comment 11•5 months ago
|
||
Backed out for causing build bustages @jsnum.cpp.
| Assignee | ||
Updated•5 months ago
|
Comment 12•5 months ago
|
||
Comment 13•5 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/9bfa7c8f85af
https://hg.mozilla.org/mozilla-central/rev/5d3df727445b
https://hg.mozilla.org/mozilla-central/rev/4beff360f7ee
https://hg.mozilla.org/mozilla-central/rev/15eed7e6983f
https://hg.mozilla.org/mozilla-central/rev/479468ad7b5c
https://hg.mozilla.org/mozilla-central/rev/4245d0b38c88
https://hg.mozilla.org/mozilla-central/rev/f529723c02d0
https://hg.mozilla.org/mozilla-central/rev/e946ef6e23cb
Updated•5 months ago
|
Description
•