Bugzilla

The current boxing scheme is correct but inefficient: when a JS string is passed to a wasm anyref, we box it, even though it is already an object (though it is a gc::Cell* not a JSObject*); when a small integer is passed, we box it, even though it could be represented as a tagged pointer.

There is (supposedly) a way to distinguish JSObject* from gc::Cell* without adding type information, so it would be good to start with not boxing string values.

With the stack map work we got a different MIR type for wasm object references, so we can use our own tagging scheme for references if we want; in particular, we can implement tagged pointers that are either references or small integers.  And we can also choose whether to use tags to distinguish JSObject* from gc::Cell* or not.

On 32-bit platforms we realistically only have two tag bits available with 4-byte object alignment, and eventually wasm will want an i31ref type, so we need to keep this in mind too.

All of this interacts in some way with bug 1508553, in which we will need to handle at least some boxing/unboxing along the optimized call paths in stubs code.

The current boxing scheme is correct but inefficient: when a JS string is passed to a wasm anyref, we box it, even though it is already an object (though it is a gc::Cell* not a JSObject*); when a small integer is passed, we box it, even though it could be represented as a tagged pointer.

There is (supposedly) a way to distinguish JSObject* from gc::Cell* without adding type information, so it would be good to start with not boxing string values.

With the stack map work we got a different MIR type for wasm object references, so we can use our own tagging scheme for references if we want; in particular, we can implement tagged pointers that are either references or small integers.  And we can also choose whether to use tags to distinguish JSObject* from gc::Cell* or not.

On 32-bit platforms we realistically only have two tag bits available with 4-byte object alignment, and eventually wasm will want an i31ref type, so we need to keep this in mind too.

All of this interacts in some way with bug 1581572, in which we will need to handle at least some boxing/unboxing along the optimized call paths in stubs code.