I’ve suggested to the maintainers of the D programming language runtime a few times that the memory allocator/garbage collector should use spinlocks instead of regular OS critical sections. This hasn’t really caught on. Here are the reasons I think spinlocks would be better:
- At least in synthetic benchmarks that I did, it’s several times faster than OS critical sections when there’s contention for the memory allocator/GC lock. Edit: Empirically, using spinlocks didn’t even have measurable overhead in a single-core environment, probably because locks need to be held for such a short period of time in a memory allocator.
- Memory allocations and similar operations usually take a small fraction of a timeslice, and even a small fraction of the time a context switch takes, making it silly to context switch in the case of contention.
- A garbage collection in the implementation in question stops the world anyhow. There won’t be any spinning during a collection.
Are there any good reasons not to use spinlocks in a memory allocator/garbage collector implementation?
On Windows anyway, critical section objects already have the option of doing this (http://msdn.microsoft.com/en-us/library/ms682530.aspx):
Hopefully other platforms will follow suit if they don’t already.