www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - one suggestion for improving the performance of gc and memroy management

reply zsxxsz <zhengshuxin hexun.com> writes:
Some days before, someone talked about the D's performance in multicore
system. dsimcha gave one suggestion that in gc using spinlock maybe better
than mutexlock. 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. In the same thread,
if some object alloc and free some memory in its own memory slice pool, no
lock will be used; If one object allocated in one thread, but be used and
freed in the other thread, the using object thread should push the object to
its owner thread, and the owner thread use timer-like method to free the
object to its memory slice pool, in this process, the owner thread's memory
slice pool lock should be used(but it's some little situation that one object
allocated in one thread and freed in another thread).
In my webserver written with C, it got the great performance improvement in
multicore system. The webserver is a noblock server, one thread can handle
above 1000 concurrent connections. Before using the thread local storage
memory slice pool, when I start one thread, I get 10000 requests/second, but
if I start two threads, I get 8000 requests/second; After using thread local
storage memory slice pool, when starting one thread, I get 10000
requests/second, if starting two threads, I get 20000 requests/second. OK,
that's real great in practice programming.
Dec 21 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-21 20:56:37 -0500, zsxxsz <zhengshuxin 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 michelf.com http://michelf.com/
Dec 21 2009
parent reply Jerry Quinn <jlquinn optonline.net> writes:
Michel Fortin Wrote:

 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.

You don't need the language to prevent the non-shared to shared cast as long as the object can be moved to shared GC once it crosses the barrier. The compiler could do this when it sees the cast happening. Jerry
Dec 22 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-22 11:39:04 -0500, Jerry Quinn <jlquinn optonline.net> said:

 Michel Fortin Wrote:
 
 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.

You don't need the language to prevent the non-shared to shared cast as long as the object can be moved to shared GC once it crosses the barrier. The compiler could do this when it sees the cast happening.

Indeed. But you still need the compiler to treat immutable and shared immutable as two different things. Currently those are synonyms semantically. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 22 2009