Defer DRC drops in host-side write_gc_ref#13842
Open
alexcrichton wants to merge 1 commit into
Open
Conversation
This commit is an update to the DRC collector to avoid immediately dropping GC references in `write_gc_ref`. This is done today by threading contextual information such as `ExternRefHostDataTable` all the way down to `write_gc_ref` and `drop_gc_ref` hooks, but a refactoring that I'm planning to do is going to make it significantly more complicated to thread all necessary contextual information through to these hooks. Specifically I'm hoping to store `TraceInfo` outside of stores and instead inside of `Module` and `RegisteredType` to avoid the need for per-type work done during module instantiation. Threading this context through these hooks is effectively ergonomically a no-go. The strategy then taken in this commit is to change the DRC allocator, the only allocator we have that needs this information during these barriers. The DRC allocator now defers full deallocation of GC allocations to a later point in time where contextual information is available (e.g. during a GC itself). This means that host-initiated writes/drops are no longer guaranteed to actually run destructors immediately (same as with the copying collector). Internally the DRC heap already has a stack of references to decrement, and previously it was only needed during a decrement operation and now it's instead modified to persist between GC barriers through to a GC itself.
github-actions
Bot
added
wasmtime:api
Subscribe to Label Actioncc @fitzgen DetailsThis issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit is an update to the DRC collector to avoid immediately dropping GC references in
write_gc_ref. This is done today by threading contextual information such asExternRefHostDataTableall the way down towrite_gc_refanddrop_gc_refhooks, but a refactoring that I'm planning to do is going to make it significantly more complicated to thread all necessary contextual information through to these hooks. Specifically I'm hoping to storeTraceInfooutside of stores and instead inside ofModuleandRegisteredTypeto avoid the need for per-type work done during module instantiation. Threading this context through these hooks is effectively ergonomically a no-go.The strategy then taken in this commit is to change the DRC allocator, the only allocator we have that needs this information during these barriers. The DRC allocator now defers full deallocation of GC allocations to a later point in time where contextual information is available (e.g. during a GC itself). This means that host-initiated writes/drops are no longer guaranteed to actually run destructors immediately (same as with the copying collector). Internally the DRC heap already has a stack of references to decrement, and previously it was only needed during a decrement operation and now it's instead modified to persist between GC barriers through to a GC itself.