forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Finalise
Gc<T>
objects on a separate thread
This prevents deadlocks in user code which acquire locks in drop methods. The new approach to finalisation works as follows: 1. During the entry_point, a finalisation thread, and an mpsc channel are initialised. 2. New threads (including the main thread) are given thread local storage (TLS) containing a sender, which is used to pass finalisers to the finalisation thread. This does not require synchronisation. 3. At the end of the GC pause, Boehm will run finalisers for objects which were not marked. This does not run the drop method for the object directly. Instead, it sends the drop method to the finalisation thread to be run later. 4. The finalisation thread iterates through the message queue, calling the finaliser callback for each unreachable object. This finaliser callback amounts to a call to `std::ptr::drop_in_place` on the object. I believe this is sound for three reasons: 1. Finaliser Safety Analysis (FSA) does not allow us to use non-Send and non-Sync fields inside a drop method, so a drop method run on another thread cannot accidentally access memory in non-thread-safe way. 2. Our modification to the BDWGC [1] which adds a memory fence at the end of a GC pause means that when a finaliser is run, it will have an up-to-date view of the object graph. If a finalisable object is mutated after a collection but before it is finalised, then this is still fine. This is because that can only happen using Sync-Send-safe containers such as a `Mutex` (as this is the only form of interior mutability supported by `Gc<T>`.) 3. Before a finaliser is run, Boehm will re-mark the object (and any others which reachable from that finaliser) which means that the object's memory will not be swept until at least the next GC (or potentially even later, if the finalisation thread has not yet run!) [1]: softdevteam/bdwgc#3
- Loading branch information
1 parent
2a214a6
commit a58c2b8
Showing
6 changed files
with
87 additions
and
36 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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