[Vm-dev] Fwd: [WebAssembly/gc] Requirements (#121)

[Craig Latta]

Hi--

     If you're interested in implementing OpenSmalltalk/Cog/Spur on
WebAssembly, this would be a good time to get involved in the WASM
garbage collection design discussion. It's getting more concrete, and
has the attention of all the major committed participants.


-C

***

-------- Forwarded Message --------
Subject: 	Re: [WebAssembly/gc] Requirements (#121)
Date: 	Mon, 24 Aug 2020 13:18:23 -0700
From: 	Thomas Lively
To: 	WebAssembly/gc


*@tlively* commented on this pull request.


Personally, I've been assuming that we are designing to optimize peak
performance for optimizing engines that will not do dynamic feedback
collection. I agree that it would be helpful to check for consensus on
what design constraints we are assuming for the top-tier of engines we
are designing for.


------------------------------------------------------------------------

In Requirements.md
<https://github.com/WebAssembly/gc/pull/121#discussion_r475869312>:

> +1. Performance is more important than convenience.
+
+   Since WASM-GC is not intended as a user-facing technology,
convenience here refers to the ease with which toolchain authors can
target WASM-GC. +   +   Convenience for toolchain authors is still
important however, as that affects adoption of WASM-GC. +
+   +## Critical Success Factors
+
+A critical success factor is an aspect or property of possible
solutions that may or may not be directly focused on the primary
objective, but none-the-less is estimated to be crucially important to
the success of the effort.
+
+1. Permit ‘cycle detection’ between host structures and language
structures; so that such cycles can be collected if there are no other
references to them.
+
+   When a WASM-GC module accesses host capabilities, or when a host
application access structures from a WASM-GC library, cross references
between them are likely to be established. For example, a DOM node may
have an event listener that is actually implemented in WASM. The event
listener, in turn, may have a reference to the DOM node it is listening
to. This represents a cycle between the host and WASM-GC. If there are
no other references to this cycles (if, for example, the DOM node is
removed) then the entire cycle must be able to be collected.
+
+1. Performance implications of WASM-GC code should be straightforward.

***

--
Craig Latta
Black Page Digital
Berkeley, California
blackpagedigital.com