From a42e26aad496ae04a1b28f4f8c3409e0f82358be Mon Sep 17 00:00:00 2001
From: Thomas Lively <7121787+tlively@users.noreply.github.com>
Date: Thu, 12 May 2022 13:27:42 -0700
Subject: [PATCH 1/2] Add method dispatch as a post-MVP feature

And document the potential performance benefits we've measured.
---
 proposals/gc/Post-MVP.md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/proposals/gc/Post-MVP.md b/proposals/gc/Post-MVP.md
index 851cb9330..bce3b5f4e 100644
--- a/proposals/gc/Post-MVP.md
+++ b/proposals/gc/Post-MVP.md
@@ -18,6 +18,7 @@ See [overview](Overview.md) for addition background.
 * [Custom function RTTs](#custom-function-RTTs)
 * [Threads and shared references](#threads-and-shared-references)
 * [Weak references](#weak-references)
+* [Method dispatch](#method-dispatch)
 
 
 ## Bulk Operations
@@ -650,3 +651,9 @@ The main challenge is the large variety of different semantics that existing lan
 Clearly, Wasm cannot build in all of them, so we need to be looking for a mechanism that can emulate most of them with acceptable performance loss.
 
 **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 reciever parameter from the top receiver type in the method's override group. As of May 2022, unsafely removing this reciever 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 reciever casts to be removed.
+
+**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.

From 79b78d9c956e40893a13248d915ac65653b3b2f3 Mon Sep 17 00:00:00 2001
From: Thomas Lively <7121787+tlively@users.noreply.github.com>
Date: Sun, 15 May 2022 09:47:25 -0700
Subject: [PATCH 2/2] Fix spelling and add note about additional opts

---
 proposals/gc/Post-MVP.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/gc/Post-MVP.md b/proposals/gc/Post-MVP.md
index bce3b5f4e..458ae3099 100644
--- a/proposals/gc/Post-MVP.md
+++ b/proposals/gc/Post-MVP.md
@@ -654,6 +654,6 @@ Clearly, Wasm cannot build in all of them, so we need to be looking for a mechan
 
 ## Method Dispatch
 
-Right now OO-style method dispatch requires downcasting the reciever parameter from the top receiver type in the method's override group. As of May 2022, unsafely removing this reciever 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 reciever casts to be removed.
+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.
 
 **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.