Removing The Global GC Lock: Largest Plausible Number of Threads?

[Jonathan M Davis]

On 2011-05-11 21:33, Jonathan M Davis wrote:
> On 2011-05-11 21:14, dsimcha wrote:
> > I'm thinking about ways to remove the global lock from the garbage
> > collector for most small allocations.  I'm basically thinking of making
> > the free lists thread local.  Every scheme I can come up with that
> > doesn't require a radical overhaul of the current implementation
> > requires every thread having a unique ID.  I want to do this as simply
> > and efficiently as possible, preferably using dense integers.  Is it
> > reasonable to assume that no program will ever need more than 2 ^^ 16
> > thread (about 65,000) simultaneously so that I can store these indices
> > as ushorts?  If a program creates a lot of short-lived threads, the
> > indices will be recycled, so having a huge number of threads
> > non-simultaneously is not a problem.
> 
> I don't think that you can legally create that many threads on a typical
> OS. I'd have to check, but as I recall, the typical limit is much lower
> than that - still in the tens of thousands, I think, but not that high.

Okay. I was wrong. Apparently, the limit on Linux is set by what's in 
/proc/sys/kernel/threads-max. On my system (64-bit Arch Linux), that's 256,245 
- though that's system-wide, so not even the most thread-happy program can 
really get all that near that limit. Still, that's far above 65,000. I can't 
find as clear an answer for Windows though. It sounds like it doesn't 
technically have a limit, but you'll run out of memory eventually. I'm not 
sure if either Linux or Windows can actually get away with having as many as 
65,000 threads at a time. And even if you can, it might be completely 
reasonable to say that druntime doesn't support more than that. That's a _lot_ 
of threads, and I find it hard to believe that any semi-reasonable D program 
would have that many. Something like erlang probably would, but I don't 
believe that they use full-on OS threads for their threads but rather do 
something more like fibers.

So, technically, I'm not sure that you can assume that 65,000 threads is 
enough, but it certainly sounds to me like it would be reasonable to enforce 
that limit on D programs, even if the OS doesn't.

- Jonathan M Davis