one suggestion for improving the performance of gc and memroy management

[Michel Fortin]

On 2009-12-21 20:56:37 -0500, zsxxsz <zhengshuxin at hexun.com> 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
michel.fortin at michelf.com
http://michelf.com/