Thread local and memory allocation

deadalnix deadalnix at gmail.com
Mon Oct 3 14:57:32 PDT 2011


Yes, I was thinking is such a thing. Each thread has a local heap and 
you have a common shared heap too, with shared data in it.

Is such a case, the flag is suffiscient because then the GC could handle 
that and trigger thread local heap allocation instead of shared one.

This is consistent with the swap friendliness I was talking about and 
can reduce the need of synchronization when allocating memory (a lock 
will only occur if the GC doesn't have any memory left in his pool for 
the given thread).

And solve finalization's thread, yes.

Le 03/10/2011 22:54, Sean Kelly a écrit :
> On Oct 3, 2011, at 12:48 PM, deadalnix wrote:
>
> There's another important issue that hasn't yet been addressed, which is that when the GC collects memory, the thread that finalizes non-shared data should be the one that created it.  So that SHARED flag should really be a thread-id of some sort.  Alternately, each thread could allocate from its own pool, with shared allocations coming from a common pool.  This would allow the lock granularity to be reduced and in some cases eliminated.
>
> I'd like to move to CDGC as an intermediate step, and that will need some testing and polish.  That would allow for precise collections if the compiler support is added.  Then the thread-local finalization has to be tackled one way or another.  I'd favor per-thread heaps but am open to suggestions and/or help.



More information about the Digitalmars-d mailing list