Use PrivateValue instead of Int32Value for ArrayBuffer{View} length and offset slots
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox84 | --- | fixed |
People
(Reporter: jandem, Assigned: jandem)
References
Details
Attachments
(9 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Length, byteLength and byteOffset values for ArrayBuffer and ArrayBufferView objects should be stored as PrivateValue so that we can easily store values > INT32_MAX on 64-bit platforms.
This will still cast values to Int32Value and won't have proper JIT support, but it's a nice step in the right direction.
Assignee | ||
Comment 1•5 years ago
|
||
This will let us store larger byteLength values in the future.
Adds a new CacheIR and MIR instruction for loading this value. The instruction
names contain Int32 because in the future this will have to bail out for non-int32
values on 64-bit platforms once we can create large ArrayBuffers. At that point we
could add a different instruction for loading the byteLength as double.
Assignee | ||
Comment 2•5 years ago
|
||
This will let us change the slot representation without having to worry about
self-hosted code accessing these slots directly.
Depends on D94830
Assignee | ||
Comment 3•5 years ago
|
||
The accessors will need more work in the future to expose the offset value in a
typesafe way without implicit casts.
Depends on D94831
Assignee | ||
Comment 4•5 years ago
|
||
Similar to previous patches. Most of the loadArrayBufferViewLengthInt32 calls will
have to be changed in the future to load the full word-size length, but at least
we now get assertion failures when larger length values show up.
Depends on D94832
Assignee | ||
Comment 5•5 years ago
|
||
@anba: I added you as reviewer because you're familiar with the VM and JIT code for this, but if you're busy I can find someone else. Hopefully the C++ changes we can do on top of this will be easier for others to review.
Assignee | ||
Comment 6•5 years ago
|
||
- Make byteOffsetValue non-static.
- Implementing byteOffsetValue using byteOffset is now more natural than the other way around.
- Move methods to the ArrayBufferViewObject base class.
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D94947
Assignee | ||
Comment 8•5 years ago
|
||
Depends on D94949
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 9•5 years ago
|
||
For consistency with the other fooValue methods.
Comment 10•5 years ago
|
||
Assignee | ||
Comment 11•5 years ago
|
||
This matches ArrayBufferObject and will let us store larger length values.
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
bugherder |
Comment 14•5 years ago
|
||
bugherder |
Assignee | ||
Updated•5 years ago
|
Description
•