More radical ideas about gc and reference counting

[via Digitalmars-d]

On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
>
>
> On 13.05.2014 13:09, "Marc Schütz" <schuetzm at gmx.net>" wrote:
>> On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 12.05.2014 13:53, "Marc Schütz" <schuetzm at gmx.net>" wrote:
>>>>
>>>> I'm surprised that you didn't include:
>>>>
>>>> 3. Thread-local GC, isolated zones (restricting where 
>>>> references to
>>>> objects of a particular heap can be placed), exempting 
>>>> certain threads
>>>> from GC completely, ...
>>>
>>> This comes up from time to time, but to me it is very blurry 
>>> how this
>>> can work in reality.
>>>
>>> Considering how "shared" is supposed to be used to be useful 
>>> (do some
>>> locking, then cast away "shared") there is no guarantee by the
>>> language that any object is actually thread local (no 
>>> references from
>>> other threads). Working with immutable (e.g. strings) is 
>>> shared by
>>> design.
>>
>> Yes, but only a part of the data is shared. I suspect the 
>> majority of
>> the data in typical programs will be thread-local. If you use 
>> a message
>> passing model, you can improve that even further (though it 
>> requires a
>> way to move an object to another thread's heap). This way, you 
>> can - in
>> the best case - avoid the shared heap completely.
>
> Possible, but this is with a language without shared data 
> (including immutable), not D. Safely transferring a large 
> object tree from one thread to another will be very expensive. 
> If you try to optimize that, the D compiler won't help you to 
> guarantee memory safety.

It certainly requires a few modifications to the language. That's 
why I think the current discussions about uniqueness, scope, 
isolated are so important, because it would fit together very 
well with memory management concepts like ARC, isolated heaps, 
and safety. For example, if the uniqueness concept that Walter 
recently added to DMD were not only temporary (only used for 
implicit conversion to immutable, AFAIU), but a real, permanent 
type modifier, transferring such a tree can be made safe at 
practically no runtime costs, apart from notifying the GC about 
the changed ownership. (No copying needs to happen, because the 
important thing for thread-local heaps is actually just in which 
thread references to objects can be stored, not necessarily that 
the actual objects are placed into physically distinct heaps.)

>
> Actually I don't have much experience with "shared" (I usually 
> use __gshared if I need a shared global). Maybe I understand 
> the idea better if you show what happens with this code when 
> run with thread local GC:
>
> class C { C next; }
>
> shared(C) list;
>
> C newC()
> {
> 	return new C; // allocated on the local heap?

Yes, because it doesn't say "new shared(C)".

> }	
>
> void prependToList(C c)
> {
> 	synchronized(list)
> 	{
> 		C lst = cast(C) list;
> 		c.next = lst;  // anything special happening here?
> 		list = cast(shared(C)) c;  // and here?

The casts are a problem. You're basically lying to the compiler, 
so this cannot work. Instead, it should be something like:

     auto newC() {
         return new isolated(C);
     }

     void prependToList(isolated(C) c) {
         synchronized(list) {
             // transfer to shared heap
             // afterwards, c is no longer usable ("consumed")
             shared(C) tmp = c.makeShared();
             tmp.next = list;
             list = tmp;
         }
     }

This uses the "isolated" concept suggested by deadalnix here:
http://forum.dlang.org/thread/yiwcgyfzfbkzcavuqdwz@forum.dlang.org?page=1

> 	}
> }
>
> void callMeFromMultipleThreads()
> {
> 	prependToList(newC());
> }