On 2009-12-21 20:56:37 -0500, zsxxsz <[email protected]> said:
I have another idea about the gc and memroy management: each thread use it's own memory slice pool with using thread local storage, which can avoiding the global lock on system memory management.
This is a pretty good idea, which happen to have been suggested on this forum a couple of time in a similar form: having a per-thread allocator, and another one shared across threads for shared objects.
In theory, this should be pretty simple to do because every variable not local to a thread thread must be tagged as shared in D2, and the compiler makes sure you don't mix them up. It'd be easy for the compiler to allocate in the right memory pool depending on whether you're instantiating a shared or a thread-local variable.
Alas, immutable breaks that nifty separation between shared and thread-local. The compiler treats everything immutable as being sharable between all threads. This means you cannot allocate immutable objects from the thread-local memory pool. And since a common pattern is to make mutable objects, then cast them to immutable, things would break there too as soon as your thread sends one of those to another thread and forget about its existence.
My opinion is that immutable and shared immutable should be two different type modifiers. Contrary to other shared values, shared immutable values can be cast to non-shared immutable (and non-shared const) since they do not require memory barriers, but the reverse should be forbidden (sending a non-shared immutable value to another thread) because it would allow thread-local objects to escape.
That would make the language much more friendly for thread-local GCs. -- Michel Fortin [email protected] http://michelf.com/
