digitalmars.D - one suggestion for improving the performance of gc and memroy management
- zsxxsz (20/20) Dec 21 2009 Some days before, someone talked about the D's performance in multicore
- Michel Fortin (27/30) Dec 21 2009 This is a pretty good idea, which happen to have been suggested on this
- Jerry Quinn (5/11) Dec 22 2009 You don't need the language to prevent the non-shared to shared cast as ...
- Michel Fortin (8/21) Dec 22 2009 Indeed. But you still need the compiler to treat immutable and shared
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
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
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
On 2009-12-22 11:39:04 -0500, Jerry Quinn <jlquinn optonline.net> said:Michel Fortin Wrote: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/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.
Dec 22 2009