wip

dotnet · Oct 9, 2023 · d390d5a · d390d5a
1 parent e9d4e8a
commit d390d5a
Showing 1 changed file with 30 additions and 27 deletions.
diff --git a/accepted/2023/wasm-browser-threads.md b/accepted/2023/wasm-browser-threads.md
@@ -272,33 +272,7 @@ Move all managed user code out of UI/DOM thread, so that it becomes consistent w
 - variation on **(13)** or **(14)** where we get rid of per-parameter calls to Mono
 - benefit: get closer to purity of sidecar design without loosing perf
     - this could be done later as purity optimization
-- offenders
-    - `Task`/`Promise`
-        - `create_task_callback`, `mono_wasm_marshal_promise`
-        - `JavaScriptImports.MarshalPromise`
-        - this will need to create something like `GCHandle`/`JSHandle` on the opposite direction and send it instead of creating it with extra call
-        - which means that we need richer interop stack frame slot, because we need to pack more information
-            - this is doable by making `MarshalerType` `byte`-based instead of `Int32`-based. This will be also good for better nested generic types if we proceed with it.
-        - this problem with "who owns the proxy", I'm still confused about it after implementing 80% prototype.
-    - `MonoString`
-        - `monoStringToString`, `stringToMonoStringRoot`
-        - `mono_wasm_string_get_data_ref`
-        - `mono_wasm_string_from_utf16_ref`
-        - we could start passing just a buffer instead of `MonoString`
-        - we will the optimization for interned strings
-    - managed instances in `MonoArray`, like `MonoString`, `JSObject` or `System.Object`
-        - `mono_wasm_register_root`, `mono_wasm_deregister_root`
-        - `Interop.Runtime.DeregisterGCRoot`, `Interop.Runtime.RegisterGCRoot`
-    - this is about GC and Dispose(): `ManagedObject`, `ErrorObject`
-        - `release_js_owned_object_by_gc_handle`, `setup_managed_proxy`, `teardown_managed_proxy`
-        - `JavaScriptExports.ReleaseJSOwnedObjectByGCHandle`, `CreateTaskCallback`
-    - this is about GC and Dispose(): `JSObject`, `JSException`
-        - `Interop.Runtime.ReleaseCSOwnedObject`
-    - `mono_wasm_get_assembly_exports` -> `__Register_`
-        - `mono_wasm_assembly_load`, `mono_wasm_assembly_find_class`, `mono_wasm_assembly_find_method`
-        - this logic could be moved to deputy or sidecar thread
-    - not problem for deputy design: `Module.stackAlloc`, `Module.stackSave`, `Module.stackRestore`
-    - what's overall perf impact for Blazor's `renderBatch` ?
+- See [details](#Get_rid_of_Mono_GC_boundary_breach)
 
 # Details
 
@@ -480,6 +454,35 @@ Move all managed user code out of UI/DOM thread, so that it becomes consistent w
     - doesn't block and doesn't propagate exceptions
     - this is slow
 
+## Get rid of Mono GC boundary breach
+- related to design **(16)**
+- `Task`/`Promise`
+    - `create_task_callback`, `mono_wasm_marshal_promise`
+    - `JavaScriptImports.MarshalPromise`
+    - this will need to create something like `GCHandle`/`JSHandle` on the opposite direction and send it instead of creating it with extra call
+    - which means that we need richer interop stack frame slot, because we need to pack more information
+        - this is doable by making `MarshalerType` `byte`-based instead of `Int32`-based. This will be also good for better nested generic types if we proceed with it.
+    - this problem with "who owns the proxy", I'm still confused about it after implementing 80% prototype.
+- `MonoString`
+    - `monoStringToString`, `stringToMonoStringRoot`
+    - `mono_wasm_string_get_data_ref`
+    - `mono_wasm_string_from_utf16_ref`
+    - we could start passing just a buffer instead of `MonoString`
+    - we will lose the optimization for interned strings
+- managed instances in `MonoArray`, like `MonoString`, `JSObject` or `System.Object`
+    - `mono_wasm_register_root`, `mono_wasm_deregister_root`
+    - `Interop.Runtime.DeregisterGCRoot`, `Interop.Runtime.RegisterGCRoot`
+- this is about GC and Dispose(): `ManagedObject`, `ErrorObject`
+    - `release_js_owned_object_by_gc_handle`, `setup_managed_proxy`, `teardown_managed_proxy`
+    - `JavaScriptExports.ReleaseJSOwnedObjectByGCHandle`, `CreateTaskCallback`
+- this is about GC and Dispose(): `JSObject`, `JSException`
+    - `Interop.Runtime.ReleaseCSOwnedObject`
+- `mono_wasm_get_assembly_exports` -> `__Register_`
+    - `mono_wasm_assembly_load`, `mono_wasm_assembly_find_class`, `mono_wasm_assembly_find_method`
+    - this logic could be moved to deputy or sidecar thread
+- not problem for deputy design: `Module.stackAlloc`, `Module.stackSave`, `Module.stackRestore`
+- what's overall perf impact for Blazor's `renderBatch` ?
+
 ## Performance
 - the dispatch between threads (caused by JS object thread affinity) will have negative performance impact on the JS interop
 - in case of HTTP/WS clients used via Streams, it could be surprizing