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

[Martin Nowak]

On Sat, 31 Dec 2011 23:28:09 +0100, dsimcha <dsimcha at yahoo.com> 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?

Not for shared libraries.
You should probably wrap multiple TLS variables in a struct and put only
a reference into TLS to reduce the expense of thread local access.