We currently use Arc for AllocatorContext. AllocatorContext is thread-local, but shared by multiple allocators in the same thread. Ideally we should use Rc for it.
However, we have allocators (including AllocatorContext) in mutators and GC workers. Our current API explicitly transfer GCWorker to a new thread, thus GCWorker is required to be Send. And whatever we use for AllocatorContext needs to be Send.
Rc is !Send. So we use Arc instead.
Rc is not Send. If it were Send, you could clone an Rc and send to another thread and the ref count would not be maintained correctly. However, for our case, we can always guarantee that all the Rc instances are sent at once, and all the Rc instances will not be used unless they are in the same thread. We could use something like https://crates.io/crates/sendable (which may be slower as they check that all the instances are from the same thread), or our own SendableRc type.
We currently use
ArcforAllocatorContext.AllocatorContextis thread-local, but shared by multiple allocators in the same thread. Ideally we should useRcfor it.However, we have allocators (including
AllocatorContext) in mutators and GC workers. Our current API explicitly transferGCWorkerto a new thread, thusGCWorkeris required to beSend. And whatever we use forAllocatorContextneeds to beSend.Rcis!Send. So we useArcinstead.Rcis notSend. If it wereSend, you could clone anRcand send to another thread and the ref count would not be maintained correctly. However, for our case, we can always guarantee that all theRcinstances are sent at once, and all theRcinstances will not be used unless they are in the same thread. We could use something like https://crates.io/crates/sendable (which may be slower as they check that all the instances are from the same thread), or our ownSendableRctype.