Skip to content
This repository was archived by the owner on Apr 25, 2025. It is now read-only.

Refine method section #303

Merged
merged 3 commits into from
Jun 1, 2022
Merged

Refine method section #303

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
47677f3
Refine method section
rossberg May 27, 2022
ab63b48
Add links
rossberg Jun 1, 2022
c319b59
Merge branch 'main' into rossberg-patch-1
rossberg Jun 1, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions proposals/gc/Post-MVP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -654,10 +654,11 @@ Clearly, Wasm cannot build in all of them, so we need to be looking for a mechan

**Why Post-MVP:** Unfortunately, it is not clear at this point what a sufficiently simple and efficient set of primitives for weak references and finalisation could be. This requires more investigation, and should not block basic GC functionality.

## Method Dispatch

Right now OO-style method dispatch requires downcasting the receiver parameter from the top receiver type in the method's override group. As of May 2022, unsafely removing this receiver downcast improved performance by 3-4% across a suite of real-world j2wasm workloads. Introducing a method dispatch mechanism into WebAssembly and its type system would allow these receiver casts to be removed and may enable additional engine optimizations for dispatch as well, making 3-4% a lower bound on the potential improvements.
## Method and Closure Typing

It is possible that method dispatch can be designed to work well with the more general [static fields](#static-fields) idea above.
Right now OO-style method dispatch requires downcasting the receiver parameter from the base class receiver type in the implementation of overriding methods. As of May 2022, unsafely removing this receiver downcast improved performance by 3-4% across a suite of real-world j2wasm workloads. A closely related problem exists for client-side encodings of closures.

**Why Post-MVP:** Method dispatch can also be easily expressed without being built into WebAssembly, so this would be a fair amount of extra complexity for a modest performance improvement and no additional benefits. Considering this as an optimimzation after shipping the MVP makes the most sense.
The problem could be addressed by extending the type system with features that allow typing the receiver/environment parameter more precisely, for which a number of solutions are known (e.g., [1](https://dl.acm.org/doi/pdf/10.1145/354222.353192), [2](http://lucacardelli.name/Papers/ObjectEncodings.pdf)). A fallback solution could be the introduction of a primitive method and dispatch mechanism besides functions, e.g., as an extension to the static fields mechanism.

**Why Post-MVP:** Methods and closures can be easily expressed without being built into WebAssembly, so this would be a fair amount of extra complexity for a modest performance improvement and no additional benefits. Considering this as an optimimzation after shipping the MVP makes the most sense.