[dmd-concurrency] Smoke test

[Robert Jacques]

On Fri, 08 Jan 2010 02:03:11 -0500, Walter Bright <walter at digitalmars.com>  
wrote:
>
>
> Robert Jacques wrote:
>> On Thu, 07 Jan 2010 20:28:23 -0500, Walter Bright  
>> <walter at digitalmars.com> wrote:
>>> Having a per-thread gc is an optimization, not a fundamental feature  
>>> of the concurrency model. For one thing, it precludes casting data to  
>>> immutable. For another, it may result in excessive memory consumption  
>>> as one thread may have a lot of unused data in its pool that is not  
>>> available for allocation by another thread.
>>> _______________________________________________
>>> dmd-concurrency mailing list
>>> dmd-concurrency at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>>
>> I would disagree; it's completely possible to allow safe casting to  
>> immutable/shared with thread-local GCs. It just requires language  
>> support. For example, adding a GC function which is called whenever a  
>> shared cast occurs. In the current GC, the function does nothing and  
>> everything proceeds as normal. With thread local GC, however, this  
>> function would publish the casted object to a list. The local GC could  
>> then pin all objects on the list and the shared GC could mark/sweep the  
>> list entries instead of the objects themselves.
>
> Sounds like the thread local pool will get peppered with shared islands  
> inside it.

Maybe. Maybe not. It really depends on how much casting one has to do  
between heap types. And whether or not that 'peppering' out-weighs the  
other benefits of local GCs. But local GCs worked in Java, where the  
regions were built dynamically and in Objective-C, where they were  
specified manually, so I think they'd work for many of D's (multi-core)  
applications. Yes it's an just an optimization, but it's an important 'use  
case' of the concurrency system in D, which makes it a good 'smoke test'.  
And if it's treated as a major 'use case' then we can identify ways around  
(and the costs) the issues (like peppering) that arise. For example:

Today, I think the major use of casting to immutable is with performance  
string building. (Non-performance code would use idup) Such code would  
probably use an ArrayBuilder. Based on that assumption, an iArrayBuilder  
could be defined to allocate from the shared/immutable memory region but  
allow fast (i.e. non-atomic) mutation. It would behave like unique and  
perform a mfence when converted to immutable/shared.