D's uses thread local storage for most of its data. And it's a good thing.
However, the allocation mecanism isn't aware of it. In addition, it has no way to handle it in the future as things are specified.
As long as you don't have any pointer in shared memory to thread local data (thank to the type system) so this is something GC could use at his own advantage.
As long as good pratice should minimize as much as possible the usage of shared data, this design choice make things worse for good design, which is, IMO, not D's phylosophy.
The advantages of handling this at memory management levels are the followings : - Swap friendlyness. Data of a given thread can be located in blocks, so an idle thread can be swapped easily without huge penality on performance. Anyone who have used chrome and firefox with a lots of tabs on a machine with limited memory know what I'm talking about : firefox uses less memory than whrome, but performance are terrible anyway, because chrome memory layout is more cache friendly (tabs memory isn't mixed with each others). - Effisciency in heavily multithreaded application like servers : the more thread run in the program, the more a stop the world GC is costly. As long as good design imply separate data from thread as much as possible, a thread local collection can be triggered at time without stopping other threads.
Even is thoses improvements are not implemented yet and anytime soon, it kinda sad that the current interface doesn't allow for this.
What I suggest in add a flag SHARED in BlkAttr and store it as an attribute of the block. Later modification could be made according to this flag. This attribute shouldn't be modifiable later on.
What do you think ? Is it something it worth working on ? If it is, how can I help ?
