Add i31ref
Categories
(Core :: JavaScript: WebAssembly, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox118 | --- | fixed |
People
(Reporter: rhunt, Assigned: rhunt)
References
Details
Attachments
(5 files)
It's not clear if we will need this in an initial GC prototype, but at some point we may need to change our tagging scheme for wasm references to support the unboxed i31ref.
Comment 1•5 years ago
|
||
FWIW, I think we should push back a little against this feature until we know that it's worthwhile for the MVP.
| Assignee | ||
Comment 2•5 years ago
|
||
Agreed, I only added this as I saw that V8 now reports it as implemented.
Updated•4 years ago
|
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 3•3 years ago
|
||
Right now wasm references area represented as a JSObject*. This is assumed in
many places in SpiderMonkey, most prominently in our GC integration
around tracing, the store buffer, and write barriers. This will cause issues
when we add tagging for JSString* values and 31-bit unboxed integers.
This commit makes wasm::AnyRef into a generally useful class and then
adds GC integration so that it behaves similar to other tagged values, such
as JS::Value.
The wasm component is then updated to use this new type wherever it
previously was assuming it.
Updated•3 years ago
|
| Assignee | ||
Comment 4•3 years ago
|
||
This is a mechanical change. The previous name 'RefOrNull' was too
generic, and it wasn't clear that the type was actually a wasm::AnyRef
type.
Depends on D177810
| Assignee | ||
Comment 5•3 years ago
|
||
Now that we have a proper wasm::AnyRef type with a tagging scheme (no
longer just a JSObject*), we will need to track it independently in
SafepointReader/Writer. This will make sure that wasm anyrefs are
traced correctly when in JS ion functions when directly calling a
wasm function.
Wasm stackmaps are also updated in this commit, but are fairly simple
because they assume everything is an anyref.
Depends on D177811
| Assignee | ||
Comment 6•3 years ago
|
||
Before this commit we would need to box a JSString* in WasmValueBox
when we received one from JS and converted to an AnyRef.
This commit adds a tag 0x2 to AnyRef to distinguish JSString* from
JSObject*. We do not use tag 0x1 as that will be used for i31ref
values. This relies on alignment of all GC cell allocations.
This commit refactors the code generation routines around AnyRef
so that they all exist in MacroAssembler. This makes it possible
to update one place when adding support for a new tag.
Our existing tests about passing values to/from externref should
be sufficient to cover this new addition. There is no user visible
change to this.
Depends on D177812
| Assignee | ||
Comment 7•3 years ago
|
||
This commit adds a tag 0x1 for 31-bit integers in AnyRef. Any JS value
that is losslessly representable (without coercion) in this range is
stored without boxing. This is chosen to line up exactly with how the
i31ref type is required to interoperate with JS.
There is now sequencing required when checking tags, first you must
check for 0x1 to look for i31 values. If that is set, the 0x2 bit is
actually part of the i31 value and should be ignored.
This commit then also adds support for the i31ref type and instructions
in validation and across our compilers. The codegeneration for it is
pretty simple. There are some MIR optimizations we could do here in
the future, but they're not important right now.
Depends on D177813
Comment 9•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/662cb63c42d7
https://hg.mozilla.org/mozilla-central/rev/cf96078694ae
https://hg.mozilla.org/mozilla-central/rev/85605041672d
https://hg.mozilla.org/mozilla-central/rev/28feda14fdec
https://hg.mozilla.org/mozilla-central/rev/72bf9c871ded
https://hg.mozilla.org/mozilla-central/rev/807d2bf018d1
| Assignee | ||
Updated•1 year ago
|
Description
•