[dmd-concurrency] D's Memory Model

[Kevin Bealer]

On Wed, Feb 10, 2010 at 1:30 PM, Walter Bright <walter at digitalmars.com>wrote:

>
>
> Robert Jacques wrote:
>
>>
>> Yes. The reason I said that casting from local to shared was
>> implementation defined was I knew the operation could be valid or invalid
>> based on the type of GC used. However, your comment sounds like the standard
>> C/C++ approach to thread-local allocation, which I discussed in the original
>> post. In short, this model has been shown to be insufficient in C/C++ with
>> regard to false sharing and has created several hacks to remove false
>> sharing for identifiable hot-spots. Your comment also doesn't address the
>> key challenge to D's GC, which is: where does the garbage returned to?
>>
>
> The garbage is returned to the global memory pool, not the local one. When
> the local ones run out, they go and get more from the global pool.


Would it be practical for particular cache lines to have some kind of
affinity for a given local allocator or for a cache line with both live and
data and garbage to have an affinity for one of the thread pools that
already owns an object within it?


>  (which I also discussed) Anyways, in order to prevent false sharing, small
>> immutable objects need their own memory pool and shared objects need to be
>> created in a different manner than local objects. To me this creates a
>> logical separation of their memory pools and at a minimum requires the GC
>> implementation to perform allocation using specific flags for each type
>> qualifier.
>>
>>
> False sharing isn't just a problem with shared objects, it happens with
> local objects. Using separate local pools to allocate from will minimize
> this problem.
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100210/c4000710/attachment.htm>