Removing the Lock for Small GC Allocations: Clarification of GC Design?

[Alex Rønne Petersen]

On 31-12-2011 23:28, dsimcha wrote:
> I have a plan to avoid the GC lock for most small (<1 page) GC
> allocations. I hope to have a pull request within a week or two, in time
> for the next release. There's one detail I need clarified by Sean,
> Walter or someone who designed the D GC.
>
> Currently small allocations are handled by popping a block off a free
> list, if a block is available. I plan to make each page owned by a
> single thread, and make the free lists thread-local. The array of free
> lists (one for each power of two size) is stored in the Gcx struct. The
> easiest way to make this array thread-local is to move it out of the Gcx
> struct and make it global. Is there any reason why >1 instance of Gcx
> would exist (maybe as an implementation detail of shared libraries,
> etc.)? If not, what's to point of having the Gcx struct instead of just
> making its variables global?

AFAIK dynamic libraries don't have the same GC instance running as an 
executable that links to it. Don't quote me on this, though.

- Alex