Track possible changes to active initializers - fallout from bulk memory proposal
Categories
(Core :: JavaScript: WebAssembly, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox67 | --- | fixed |
People
(Reporter: lth, Assigned: lth)
References
Details
Attachments
(1 file)
Filed some issues here: https://github.com/WebAssembly/bulk-memory-operations/issues/56. Contrary to intent, memory.init + data.drop is not equivalent to active segment initialization, ditto for tables, due to handling of bounds checking.
Most likely this will result in tweaking the semantics of active segment initialization, since that will also make the most sense in the presence of shared memory and concurrent memory.protect.
Such tweaking will need to be reflected in our implementation.
|
Assignee | |
Comment 1•5 years ago
|
||
Semantics of active segment initialization have been tweaked suitably (https://github.com/WebAssembly/bulk-memory-operations/pull/57) and we need to update SpiderMonkey to follow suit, under an ifdef initially.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 2•5 years ago
|
||
The bulk memory proposal changes the meaning of active initializers:
they are to be applied in order (tables before memories), performing a
bounds check at every write, and erroring out only at the first OOB.
Since bulk memory is not yet shipping there's a regrettable amount of
ifdeffery here, both in code and tests, but that will get cleaned up
once we have shipped.
Pushed by lhansen@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e64056f5ed21 Active initializers can write partial data. r=jseward
|
||
Comment 4•5 years ago
|
||
| bugherder | ||
Description
•