[dart2wasm] finalize approach for typed data

[yjbanov]

Even though #52710 is considered fixed, there's still a lot of discussion around typed data. So filing an issue to track those discussions. Collecting various pieces of information from various threads:

Dart provides the dart:typed_data library. Two major use-cases for this library are:

• Efficient storage of and access to arrays of typed numerics. For example, package:vector_math uses Float*List to store matrix data. Flutter uses it to perform layout computations.
• Data exchange across interop boundary, such as passing data to browser API (WebGL, network, image decoding), and exchanging data with the Flutter Engine (a Wasm module compiled from C++).

More generally, the following are properties of typed data that Flutter currently assumes:

• Fast allocation of typed data at least the length of a Float64List(16) (e.g. the Dart VM bump pointer allocates them).
• Fast access to data (e.g. the Dart VM incurs only a range check that may be elided in some cases).
• Integrated with the GC (no explicit code needed to free the data, GC is aware of the amount of memory taken by the typed data).
• Fast interop with the Flutter Engine (passing data to the C++ code).
• Fast interop with platform API (passing data to WebGL, network, file I/O, native libraries, etc).

The Dart VM checks all these checkboxes. V8 checks all, except allocation (it incurs a malloc) and fast access (it is slower compared to the Dart VM), but since JavaScript doesn't offer anything better, there's not many options to choose from.

The wasm story is a bit more complex, because it has multiple potentially viable options:

• WasmGC offers efficient storage for numeric data (array i8, etc), but:
  • It does not support reinterpreting the data to a different number type (Multibyte access to (array i8) WebAssembly/gc#395).
  • WasmGC arrays are opaque to JavaScript and most browser APIs do not (yet?) accept them. For example, you cannot take an array i8 and pass it to ImageDecoder to decode an image, or create a WebGL texture. To pass data from WasmGC arrays, it needs to be copied to JS, which can be slow.
• The linear memory can store type data, supports reinterpretation, and provides fast access both in wasm and JS, but:
  • It is not integrated with the GC. It requires extra work and overhead to integrate via FinalizationRegistry, although even that may not be sufficient because the GC also needs to know the size of the memory that typed data takes.
  • Allocation uses malloc/free (rather than the faster pointer bump GC allocator).
  • It makes combining Dart wasm modules with C++ wasm modules a bit more complicated because both would be using the same linear memory (somehow need to share a malloc/free implementation).
• JavaScript has typed arrays that are already well-understood by and need zero copy to pass to the browser API, support reinterpretation, integrate with the GC, but:
  • Are noticeably slower than WasmGC arrays due to extra features, such as "attachedness" and dynamism.
  • Slower to access from Wasm.

It seems no one option checks all the checkboxes, so we'll need to be creative. Things to consider:

• What's wasm's long-term plans? Should we pick something that would later be easy to move to something better? For example, perhaps accessing JS arrays from wasm can become fast, and/or browser API can be taught to take WasmGC arrays, and/or Multibyte access to (array i8) WebAssembly/gc#395 will be fixed.
• Can Flutter's usage of typed data be changed? For example, what if we stop using typed data for vector math?
• Can Dart standard libraries separate types into "internal" (fast in-heap data) and "external" (less fast to access, but fast to exchange)? Then we'll pick the type appropriate for the use-case instead of using one type for all use-cases.
• How fast do these types need to be? Perhaps the Dart VM level performance is not required? Maybe there's a middle solution somewhere:
  • What would be "good enough" perf for vector math?
  • What's the cost of copying between wasm and JS?