[wasm] Add an internal GC lock API #82646
Conversation
|
/cc @pavelsavara @lewing |
|
Tagging subscribers to 'arch-wasm': @lewing Issue Detailsnull
|
lambdageek
force-pushed
the
feature-blazor-gc-lock
branch
from
ab2380a to
dc936c1
Compare
This is an exported API, so we're normally in GC Safe mode on entry
lambdageek
changed the title
|
Proposed Blazor change is dotnet/aspnetcore#46909 |
lambdageek
requested review from
lewing,
kg,
BrzVlad,
vargaz and
naricc
as code owners
|
Changes look good to me, I was just wondering what the use case is; would it make more sense to implement GC.TryStartNoGCRegion instead? |
Not sure a C# API is what we want in this case. the Blazor rendering code is in JS. Although if we end up implementing that API, we could probably update these new APIs to use the same underlying mechanism. |
|
Why does the blazor rendering code need to lock on gc ? |
So the way blazor rendering works is that on the C# side they build up a managed object that describes the DOM changes that they want to apply, and then on the JS side they run something that crawls over this object and applies the DOM mutations. They use unsafe In single-threaded wasm this is GC safe, because there's a single thread and it's currently busy doing JS work. In the short term it's not possible to change Blazor to use GC handles or anything like that. So our plan is:
|
|
@BrzVlad any objections? |
Take the runtime's GC lock when creating a heap lock. **Important Notes** 1. While the runtime GC lock is locked, calling any C# function or doing anything that may trigger managed allocation will block the runtime. 2. In a threaded build, only the main browser thread is allowed to call the `mono_wasm_gc_lock` function 3. The runtime lock is not recursive 4. Background threads initially continue running, so the managed object graph may change even while the GC lock is held (although objects may not move). Background threads could mutate valuetype fields of reachable objects, even while the GC lock is held. However background threads will block as soon as they try to do any allocation. 5. The main browser thread may assume that managed heap objects will not move while the lock is held. Corresponding runtime change dotnet/runtime#82646
ghost
locked as resolved and limited conversation to collaborators
No description provided.