Is GC opt-in? #66
Comments
|
If you don't use any of the allocation instructions then no GC should ever be triggered. We also intend to identify optional parts of Wasm, which engines in a specific embedding environment could choose not to provide. This seems desirable for a number of features like GC, threads, or SIMD. (I'll ignore your trollish comment about stuttery land. ;) ) |
|
The intent has been for the GC feature -- eg struct types and (ref T) types -- to be optional for a wasm implementation. If it is supported the implementation will support garbage collection of some sort, and with that there's always the risk of GC pauses (*) if GC is triggered while wasm is running. But that's true for all the in-browser wasm implementations already. If the implementation supports GC it's also likely that the implementation will garbage collect a lot of its own data structures, so the fact that your program does not allocate GC objects really need not have any impact on whether GC is triggered - allocation that drives GC may happen anyway. (Yes, this contradicts what @rossberg just wrote; I think he's wrong.) (And of course in a web environment there's so much going on the browser that GC while wasm is running is basically inevitable, whether the GC feature is supported or not. Other embeddings are easier to reason about.) (*) I think the browsers mostly have incremental and/or concurrent GCs these days, reducing stuttering significantly, modulo bugs. |
|
@lars-t-hansen, you're right, but any such GC is an implementation choice and nothing Wasm would require. Conceptually, it is orthogonal to the question of in-Wasm GC. In particular, all production engines today already do that, so nothing changes by adding GC instructions but not using them. |
|
This is a big concern to me, as I thought GC would be strictly opt-in. I'm working on an SDL app written entirely in Rust and highly focused upon fast operation. Being forced to diddle around with GC in the future makes me shudder. |
|
@jpryne, as explained above, it is optional in any sense you should ever care about. You can completely ignore it if you don't need it. |
Sorry, I may have had a misconception.
Is GC in WASM different? Is it the type of GC that destroys objects as soon as they go out of scope? Are there two types of GC in play here (in-wasm and out-of-wasm)? Which of those does the spec cover? What are the differences? Based on #36, any language today can implement their own GC in WASM, right? Is that is what you mean by in-wasm GC? That issue was also wondering about Stutterville 🚎 . |
When I heard "GC", I was thinking about batched GC where the collector runs once in a while, and at these points the main thread UI can stutter.
|
Another question: Is this GC feature strictly required in order to enable interaction with DOM or JS objects? Or is it only the current design? |
|
I guess, I just don't want to get hyped on WASM for solving some issues (stutter), and then end with the same problems that I think would be nice to avoid by moving to WASM. I suppose it will require understanding of which sort of GC each language implements. |
This will only occur if you allocate GC objects. Is there nothing to garbage then the GC will never run.
DOM an JS objects are GC managed objects. This is independent of the use from WASM. You does not need to use any GC object inside WASM. But self if you use a proxy inside JS to access a DOM object from WASM then you allocate GC objects. This is already valid today.
Are you sure that the stutter of a web page is the result of a GC and not of the single thread problem of JavaScript? I does not will discus this here. There are better places. Just a thought. |
* The data count section is required if the `memory.init` or `data.drop` instructions are used. * `memory.init` had an off-by-one bug when reading at the end of a segment. * All instructions that operate on regions need to compare length to 0 using unsigned comparison (e.g. `I32.gt_u n 0l`). * Converting length from 32- to 64-bit now uses `I64_convert.extend_i32_u`, instead of `Int64.of_int32`, since the latter will sign-extend. * The `table.copy` overlap test now uses an unsigned comparison. * The passive element text syntax still allows function indexes, e.g. `(elem passive $f1 $f2)`. * Add element type to passive element segments
|
Closing this because the original question has been answered. |
What I'm hoping is that we don't get into stuttery-land because of GC, and that it can be an opt-in feature inside of specific parts of a wasm module. I bet this is the case, but I'm just curious to know.
Should wasm even have GC? (I know there's the other thread for that)
The text was updated successfully, but these errors were encountered: