Relationship between GC and JSDom proposals?

[DLehenbauer]

Has there been any discussion regarding how the JSDom pre-proposal aligns with the GC proposal?

For example, one could imagine achieving the primary goal by decoupling and prioritizing imported host types from the larger challenges that the GC proposal takes on.

(FYI - @flagxor, @lukewagner)

[lukewagner]

Yes, we're specifically thinking about these proposals as complementary and that the host types are indeed a good first incremental step towards the much larger GC picture.

But the end goal, I think, is that valtype (the types of values you can use in locals and expressions) will be unified with the elemtype (the types of values you can stick in a Table) and there will be get_elem/set_elem ops to go back and forth.

[DLehenbauer]

If I understand correctly, the JSDom proposal introduces an (optionally importable) pinned table of object references.

Currently, we cannot assign an element in this table to a local or pass one as a parameter to an imported function because locals, parameters, etc. must be typed as one of i32|i64|f32|f64. To work around this, the proposal includes a mechanism for invoking an imported function using i32 indices that resolve to objects in the pinned table.

However, someday we hope to expand the set of types we can assign to a local so we can assign an object reference directly to a local, pass it directly to function, etc. w/o conversion to/from indices into the table.

@rossberg - Were you thinking JavaScript objects imported into wasm would be anyrefs?
@lukewagner - If script puts a reference to a DOM object into the import table, were you planning for anything different to happen than when it's a reference to a JS object?

[lukewagner]

I guess it depends what the element type of the Table is. For the element type external, then both DOM and arbitrary JS objects could be put into the table (actually, I assume it means any JS value).

[titzer]

I support introducing anyref as a type, since we will need it in the long run. I wonder if it is worth it to allow a module or host to specify a subtype of anyref, e.g. JSValue, that would prevent confusion with other types that are also implicitly subtypes of anyref.

[rossberg]

The idea was that modules can import types defined by the host. Then a reference to such a type naturally is a subtype of anyref.

[titzer]

I don't think we should assume that all host types are necessarily subtypes anyref. E.g. maybe a host wants to expose an opaque type whose underlying representation is i32 or i64. One example could be the type of a file descriptor on unix/posix.

[titzer]

Capturing some offline discussion with @rossberg here.

Importing a host type with an unknown representation could be a problem for engines, since they may want to, for example, compile machine code for a module, and that requires knowledge of the representation (e.g. a reference vs an i32 or i64).

If we require an imported type to specify a representation constraint (and probably only supporting anyref for now), then we would be future-compatible for the use cases I mentioned without adding a lot of complexity.

Thoughts?

[rossberg]

There is a bit a of a mismatch with how the type section works right now, since it does not define value types such as anyref, but data types that you can create references to (e.g., struct itself is not a subtype of anyref, only (ref $struct) is). So this would imply a notion of an explicit kind system for things in the type section. That may make sense, but of course is a new dimension of complication.

We could keep the kinds implicit if we inverted the scheme: everything that is not a referencable type must be specified with an explicit transparent representation, but it can be declared to be "private".

[titzer]

Right. Locally defined types have an implicit representation, whereas imported types have unknown representation. It is probably OK to have an implicit anyref representation for imported types, with space in the binary encoding to override it in the future.

[lukewagner]

That's a good point, I like the idea of host imports specifying a representation type.

[DLehenbauer]

Just checking my understanding that the need for a representation type is a host-specific implementation detail that depends on what kind of types a host wants to support importing...

For example, if the host chooses to support importing something like C# structs, which are value types that can embed GC references at arbitrary offsets, the host will need to specify the representation in sufficient detail to cope w/that complexity. (Or perhaps fall back on boxing?)

However, for the JSDOM scenario which only exposes importing refs to JS or DOM objects, anyref continues to be a simple? (I think that's what @titzer was pointing out.)

[rossberg]

I don't think non-scalar value types like C# structs would make sense for Wasm. Its premise is that it abstracts the machine, not a source language, and features like that ought to be compiled away.

Ben's concern is that you might want to represent some host types (or even user types) as unboxed numbers for performance reasons, yet keep them conceptually opaque e.g. for security. But to be able to generate code the compiler still needs to know their representation.

[lukewagner]

A related representation concern is that some types will require a full jsval box whereas other types could just be a raw GC pointer (with all the type in the GC header).

[DLehenbauer]

Any opinions on changing the proposed JSDOM approach to:

• Add the anyref type to WebAssembly’s type system
• Allow at least one additional table of type anyref to be defined or imported into modules table.
• Add get_elem/set_elem as proposed above.

(It wouldn't be amenable to being polyfilled, but avoids the custom section of binding conversions.)

[DLehenbauer]

I think we can close this, as the discussion has moved to the new host-bindings repo (thanks @titzer!)