Closed Bug 1692065 Opened 5 years ago Closed 3 years ago

Add i31ref

Categories

(Core :: JavaScript: WebAssembly, task, P3)

task

Tracking

()

RESOLVED FIXED
118 Branch
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.

FWIW, I think we should push back a little against this feature until we know that it's worthwhile for the MVP.

Agreed, I only added this as I saw that V8 now reports it as implemented.

Severity: -- → N/A
Type: task → enhancement
Blocks: wasm-gc
No longer blocks: 1625595
Type: enhancement → task

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.

Assignee: nobody → rhunt
Status: NEW → ASSIGNED

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

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

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

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

Pushed by rhunt@eqrion.net: https://hg.mozilla.org/integration/autoland/rev/662cb63c42d7 wasm: Create a unique wasm::AnyRef type. r=yury,jonco https://hg.mozilla.org/integration/autoland/rev/cf96078694ae wasm: Rename MIRType::RefOrNull to 'WasmAnyRef'. r=yury https://hg.mozilla.org/integration/autoland/rev/85605041672d wasm: Update safepoints to track AnyRef. r=jandem https://hg.mozilla.org/integration/autoland/rev/28feda14fdec wasm: Add tagging for JSString* in AnyRef. r=yury https://hg.mozilla.org/integration/autoland/rev/72bf9c871ded wasm: Add tagging for 31-bit integers and i31ref. r=yury https://hg.mozilla.org/integration/autoland/rev/807d2bf018d1 apply code formatting via Lando
Blocks: 1847871
Regressions: 1847524
Regressions: 1851569
Regressions: 1854068
Regressions: CVE-2025-1011
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: