Comments (15)
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.
from gc.
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?
from gc.
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).
from gc.
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.
from gc.
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.
from gc.
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.
from gc.
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?
from gc.
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".
from gc.
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.
from gc.
That's a good point, I like the idea of host imports specifying a representation type.
from gc.
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.)
from gc.
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.
from gc.
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).
from gc.
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.)
from gc.
I think we can close this, as the discussion has moved to the new host-bindings repo (thanks @titzer!)
from gc.
Related Issues (20)
- Type matching with recursive types HOT 8
- In the latest standard, ref.extern is gone, but its use still exists in test. HOT 3
- Type equivalence in modifiend spec HOT 1
- [spec] array.init_elem: bounds check correct? HOT 1
- Request for clarification: is this Wasm valid or not? HOT 2
- validation rule of `ref.is_null`, `ref.as_non_null` and `ref.cast` HOT 7
- Dynamically initializing a non mutable array HOT 4
- Does the combo of subtyping and unreachable code require actual type inference? HOT 41
- Question about the sub-typing rules HOT 15
- [js-api] Throw LinkError consistently
- How to reinterpret `(array f32)` to `(array u8)`? HOT 1
- [Question] About GC heap area and linear memory HOT 1
- Working with wit component HOT 4
- Inconsistency in validating global HOT 2
- Array copy specification potential incorrect mutable assertion HOT 4
- Bounds check is possible wrong on array.copy/array.fill HOT 1
- Type of active element segments HOT 10
- Effects of optimized out instructions HOT 5
- Portability hazards of i31ref with non-native engines HOT 1
- Questions about multiple inheritance HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gc.