1598009 - Generalize ValType reference types

Status: RESOLVED FIXED

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

Description

[Lars T Hansen [:lth]]

At the moment, we have AnyRef, FuncRef, NullRef, Ref, and I'm about to add ExnRef, and there's a lot of churn when we add a new one, and in the long term this is not going to be sustainable. Better to have a single "Ref" idea and some ways of talking about the opaque subtypes.

This will amount to removing ValType::AnyRef, ValType::FuncRef, and ValType::NullRef, and inserting special cases when those are handled differently from just ValType::Ref, but this is less often than you'd think, so generally this will be a simplification for a lot of the code.

We'll then introduce type-safe dispatch when we have a reftype. Code will still initially switch on the typecode and what is now multiple cases, one for each reftype, will move in under a secondary switch under the ValType::Ref case.

Comment 1

[Lars T Hansen [:lth]]

Attachment: Bug 1598009 - Simplify ValType

Comment 2

[Lars T Hansen [:lth]]

Attachment: Bug 1598009 - Use the simpler ValType

Depends on D54003

Comment 3

[Lars T Hansen [:lth]]

Those patches compile but I haven't tested them yet because my Linux install borked itself when I tried to upgrade to Fedora 31 this morning; I can't currently run jit_tests, something is really, really broken with Python. (Also, those patches are somewhat WIP, the style of the rewrite is not quite consistent.)

Comment 4

[Lars T Hansen [:lth]]

Attachment: Bug 1598009 - Generalize ValType reference types. r=luke

ValType is changed so that it only has one reference type, ValType::Ref.
That type now subsumes FuncRef, AnyRef, NullRef, GC ref types, and in
the future also exnref and other event references.

Most consumers of ValType need know nothing more than Ref, so we can
remove a lot of code in switches and importantly won't need to add code
many places in the future.

Other consumers do need to distinguish different types, and for them we
provide ValType::refType(), which returns a RefType value, which does
distinguish among the reference types. Thus most switches will first be
on ValType to get to ValType::Ref, and then in some cases further switch
on the refType to implement specialized code.

By and large, NullRef is being rolled into other Ref cases in this patch,
since Ref is frequently either the generic case ("what's the size of a
pointer?") or an error case ("no (ref T) support here yet"), this is going
to be a fine basis on which to implement further nullref support when we
need it.

The main cost for this in the present patch is that ValType retains its old
representation as a PackedTypeCode datum, and so to return ValType::Ref
from ValType::code() we need to perform an extra test. This test slows
down baseline single-threaded compilation of Zen Garden by 1-2%. I think
this is affordable. The alternative is to change the representation of
ValType so that those that are dependent on its PackedTypeCode representation
instead compute that; I judged that to be more brittle, but we can
revisit it if need be.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6438be326666
Generalize ValType reference types.  r=luke

Comment 6

[Oana Pop-Rus]

Backed out 2 changesets (bug 1599125, bug 1598009) for build bustages in WasmTable.h

Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=superseded%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&revision=dc6998f9d728284f2808b1711cdb52f025886a71&selectedJob=280855180

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=280855180&repo=autoland&lineNumber=5255

Backout: https://hg.mozilla.org/integration/autoland/rev/669e33b257e8690c1a82a36514d152f93028b4fd

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/348f26ca8d22
Generalize ValType reference types.  r=luke

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/348f26ca8d22