Closed Bug 1593640 Opened 5 years ago Closed 4 months ago

Do not allocate a box for JS string values that are boxed into anyref

Categories

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

enhancement

Tracking

()

RESOLVED FIXED

People

(Reporter: lth, Unassigned)

References

(Blocks 1 open bug)

Details

JS string values can be boxed as pointers, we just need to distinguish a string* from a JSObject*, since a string is a gc::Cell. We'll fix this by making RefOrNull a richer implementation. Specifically, the low two bits are available for tagging. We'll assign these tags:

0b00 -- JSObject*
0b10 -- string*
0b_1 -- unused

On the path from JS->wasm, we are either in a situation where we have a Value and we're run-time testing it, or we have type information that the value is a string*. In the case where we have a Value we must distinguish a gc::Cell from a JSObject*, and there's supposedly a standard song and dance for doing that. Code is already performing this testing in callImport (for return values), callExport (for arguments), and in the ditto stubs, and on the "no type information" in the Ion->Wasm fast path. In the case where we have type information, we can just tag the pointer directly.

On the path from wasm->JS, we know we have an anyref and we just need to check the tag bit, and if it says string we unbox the string by stripping the tag bit and storing it in a Value, and otherwise we do what we currently do to unbox an anyref into a Value with tag tests and/or loads.

We'll also need to update the tracing logic so that RefOrNull values are handled correctly even when tagged.

I'll mark this as blocking reftypes, though it doesn't really.

No longer blocks: wasm-reftypes
Assignee: lhansen → nobody
Status: ASSIGNED → NEW
Severity: normal → S3

This was implemented in bug 1692065.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.