fix Issue 15822 - InvalidMemoryOperationError when calling GC.removeRange/Root from a finalizer

[MartinNowak]

• use separate locks for GC.add/removeRange/Root
• avoids GC.lock contention for manual memory management

[dlang-bot]

Fix	Bugzilla	Description
✓	15822	InvalidMemoryOperationError when calling GC.removeRange/Root from a finalizer

[WalterBright]

Auto-merge toggled on

[DmitryOlshansky]

Wouldn't this deadlock in situation where:

1. thread A calls addRange and takes the "add range" lock
2. thread B starts GC collection
3. Some finalizer calls removeRange

[rainers]

Should be ok because finalizers are run in the sweep phase, but the locks are only held during marking.

[MartinNowak]

thread A calls addRange and takes the "add range" lock
thread B starts GC collection

A deadlock can happen if you have a possible lock-order inversion or more generally a cycle in the lock-order graph.
Let's see.

rootsLock -> mallocLocks
rangesLock -> mallocLocks
gcLock -> rootsLock -> mmap (no other locks during marking)
gcLock -> rangesLock -> mmap (no other locks during marking)

Threads aren't suspended while holding the locks. Looks fine.
In particular it would still allow for parallel/asynchronous finalization.