Requirements

[fgmccabe]

This is a draft requirements document to help guide our decision making on GC.

Comments and suggestions are more than welcome.

[tlively]

One thing that has come up in various discussions but is not addressed here is separate compilation. Is it a goal or non-goal for the GC proposal to support separate compilation to separate WebAssembly modules that will be instantiated together on the client? Is it important that specific ABI details are able to be abstracted away on the module boundary so that changing the definition of an item in one module does not necessarily require recompilation of all the other modules that use it?

[fgmccabe]

JS is on TIOBE, of course. But it is off this list because JS already exists in most (all) environments in which WASM exists.

[dcodeIO]

I can't stop wondering about the reluctance to design Wasm GC with JS in mind. If these two don't have great interop, everyone (or every language for that matter) using Wasm GC in a browser will suffer. Of course Wasm GC needs to be great to be targeted by AOT compiled languages, no doubt, yet not at least granting JS special status as our primary interop target exactly because "JS already exists in most (all) environments in which WASM exists", and designing accordingly, will require every GC'ed language to inefficiently bindgen or interfacecopy their way around it forever, don't you think?

[lars-t-hansen]

@dcodeIO, not sure where you're coming from with that. Excellent, fast JS interop is a hard requirement from the browser point of view - objects must be shareable between JS and wasm with very fast access from both sides (and there are now two competing proposals for how to accomplish that). In practice, browsers will use the JS heap and JS GC to manage wasm objects and layouts will be compatible enough for interop to be practical. Features of wasm GC that are hostile to current JS / browser GCs - for example, elaborate tagging schemes coupled with a requirement for uniform representations - may have a hard time getting accepted by the browser makers.

[dcodeIO]

Excellent, fast JS interop is a hard requirement from the browser point of view

I'm inclined to just take your word for it, yet I'd prefer if the document clearly stated that. The closest there is so far is the paragraph on "code migration" (contains the only four search hits for "JavaScript" in the entire document btw), but I'd argue this one should really just be "Excellent, fast JS interop", not bound to any specific use case or implementation detail, to avoid any misconceptions like (hopefully) mine.

[RossTate]

My high-level suggestion would be to take the Phased Release section and move it to after Goals and before Criteria. Within that section should be discussion of prioritization and overspecialization, which seem to be the two items causing the most discussion. That is, we need to prioritize the features we release across phases in some manner, but we should also strive to do so without overspecializing towards those features (which is often the easiest short-term way to achieve a prioritization, but which has long-term downsides). Then clarify that the subsequent goals, requirements, and CSFs are long-term, i.e. for the GC project as a whole, and that determining such goals, reqs, and CSFs for the first phase needs to be done.

On the topic of specific languages, this sets us up so that we always stand to benefit from the insights of all languages even if they are not the ones being prioritized for the current phase. They are the best equipped to inform us of overspecializations we might be making unintentionally. Also, ideally we have separate documents for the immediate phase, the next phase, and the long-term vision, and non-priority languages can help us work on later documents (which might inform earlier documents if unexpected conflicts arise).

On the topic of JS interop, this encourages us to find ways to provide excellent JS interop (a high-priority item) without overspecializing to JS. Maybe we'll discover that that's impossible, but I'd like us to at least explore the possibility before shortcutting to building the JS object model into WebAssembly.

[binji]

To everyone who's reviewed this so far -- are there any outstanding concerns?

[tlively]

The only thing in the current version that I found surprising was requirement 6, "Support for multiple GC 'memories'." It says that this is intended to improve compositionality, but I don't see how having isolated heaps is more composable than a single shared heap. IIRC, we discussed this idea in the context of @Brion's use case of limiting available resource, but that higher-level goal isn't mentioned in the document.

[RossTate]

Oh yeah, I was surprised that hadn't spurred more discussion. I pondered the idea for a while and I think it has some merits:

1. It encourages a useful (in my belief) mental model of applications operating in largely separate spaces but with sparse/explicit cross-references into other applications' spaces (or the host's space).
2. It has potential for managing resources, addressing the concerns that @Brion brought up.
3. It could be a performance win. If it's easier to identify closely related heap values, they can be allocated more closely and they could be managed more closely. For example, a GC could regularly just collect garbage within heaps, and only infrequently do a larger-scale collection looking for cycles due to cross-references across heaps. This could be a way to bring up the (alarming-to-me) issues that @KronicDeth brought up.

Regardless, I feel like it needs more explicit discussion.

[aardappel]

Yup, would agree that having separate GC spaces can help avoid a "tragedy of the commons" both in terms of performance and assigning blame for memory usage. This was an explicit goal of #78 too.

[MaxGraey]

It could be a performance win. If it's easier to identify closely related heap values, they can be allocated more closely and they could be managed more closely. For example, a GC could regularly just collect garbage within heaps, and only infrequently do a larger-scale collection looking for cycles due to cross-references across heaps. This could be a way to bring up the (alarming-to-me) issues that @KronicDeth brought up

I Immix GC / RC approach even better in this situation. btw GHC already experiment with this

[fgmccabe]

Some arguments for having multiple 'gc spaces':

1. It allows multi-threaded languages (such as Java) to work without conflicting with the 'main loop'. Recall that GC-ing does take time from the main loop.
2. It supports languages like Erlang that effectively have a combination of an arena memory model and regular GC.
3. It helps with 'tragedy of the commons'. A typical GC oriented language is going to invoke the GC quite frequently. Perhaps much more frequently than the collector would normally be invoked by the renderer engine and/or JavaScript itself.
4. It mirrors the multiple memories proposal (this is a kind of 'bureaucratic tidiness' argument).

FWIW, arg #1 was the reason that I originally thought about having multiple GC memories. OTOH, this is definitely something that can be staged for a later release.

[RossTate]

OTOH, this is definitely something that can be staged for a later release.

I'm not sure that's true. If it helps to statically ensure some separation of heap regions, that's hard (impossible?) to do with a top type (like anyref). That is, while actually giving people the ability to actually construct separate heaps can be staged for later, it might require planning now to leave room for that. 😕

[fgmccabe]

Can we land this?

[dcodeIO]

I still wonder how we'd manage to achieve meaningful code migration / interop with the web given that interop is now mentioned in the document, yet the bottom line remains that it is "impossible" (#145 (comment)) or that "GC is not responsible" (#145 (comment)). To me it seems that there are conflicting requirements here: We either cheap out on good interop, so code migration etc. will be hard to achieve in the first place or become cumbersome/inefficient, or we don't so things become "possible", implying that "GC is (at least partially) responsible". As such I'm not sure that we should commit to it just yet, as we may easily paint us into a corner that even interface types can't fix.

[rossberg]

I think this crucially needs to say something about separate compilation, linking, and being usable in conjunction with Wasm modules. Also, please fix spelling of Wasm. ;)

[taralx]

Should the file live under proposals/gc? To minimize churn we can probably move it right before merging.