On Thursday, 18 June 2015 at 14:11:42 UTC, ketmar wrote:
> On Thu, 18 Jun 2015 12:08:10 +0000, Etienne Cimon wrote:
>
>> On Thursday, 18 June 2015 at 11:43:18 UTC, ketmar wrote:
>>> On Wed, 17 Jun 2015 22:35:12 +0000, Etienne Cimon wrote:
>>>
>>>> e.g. __gshared MyObj g_obj1;
>>>> 
>>>> Thread 1: g_obj1 = new MyObj;
>>>> Thread 2: g_obj1.obj2 = new MyObj;
>>>> Thread 3: write(g_obj1.obj2); <-- access violation (probably)
>>>
>>> so no way to anchor the whole object tree by assigning it to __gshared root? sure, this will never make it into mainline.
>> 
>> __gshared is a little sketchy. We can have TLS GC by default by piping `new shared` to a shared GC. It's even safer, because then we have the type system helping out.
>> 
>> e.g. shared MyObj g_obj1;
>> Thread 1: g_obj1 = new shared MyObj;
>> Thread 2: g_obj1.obj2 = new shared MyObj;
>> Thread 3: write(g_obj1.obj2); <-- success!
>
> besides, wouldn't it break `std.concurrency`? (ketmar have to dig into code instead of asking...)

If it does, we fix it. I've never seen druntime/phobos mismatched versions (2.067 & 2.066) compiled together successfully, we shouldn't allow a necessary change to be blocked because of this alone.

As a workaround, you can also do __gshared MyObj g_obj1 = cast() new shared MyObj;

On Wednesday, 17 June 2015 at 22:21:21 UTC, Laeeth Isharc wrote:
>
> Do you have any links to reading material on this type of GC?
>
This comes to mind, along with the citations:
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/local-gc.pdf

-Wyatt

On Thursday, 18 June 2015 at 15:09:46 UTC, Wyatt wrote:
> On Wednesday, 17 June 2015 at 22:21:21 UTC, Laeeth Isharc wrote:
>>
>> Do you have any links to reading material on this type of GC?
>>
> This comes to mind, along with the citations:
> http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/local-gc.pdf
>
> -Wyatt

That's exactly what we're talking about, but we do the work that was done by the globalisation policy by using the `new shared` keyword. We end up with a language that support the very foundation of what I'd say is the most solid Garbage Collection model.

"To  summarise  these  results,  it  seems  that
although  the  local  heap  collector  performs  many  fewer  young-
generation collections and fewer synchronisations, the benefits are
offset  to  some  extent  by  the  extra  work  being  done  by  the  col-
lector to maintain the global-heap invariant. "

"Globalising  the  entire  transitive  closure  was  on  average  93%
slower, and results ranged from 7% faster to 577% slower."

"A garbage collector with local per-processor heaps can outperform
a stop-the-world parallel garbage collector in raw parallel through-
put, and exhibits more robust performance through having fewer
all-core synchronisations. "

On Thursday, 18 June 2015 at 15:19:19 UTC, Etienne wrote:
> On Thursday, 18 June 2015 at 15:09:46 UTC, Wyatt wrote:
>> This comes to mind, along with the citations:
>> http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/local-gc.pdf
>>
>> -Wyatt
>
> That's exactly what we're talking about, but we do the work that was done by the globalisation policy by using the `new shared` keyword.

Maybe I misunderstood.  My interpretation was you were disallowing references from shared heap to local heap and obviating the whole globalisation problem.  No migrations; just explicit marking of global objects with "new shared". (Though I'm curious how you handle liveness of the global heap; it seems like that depends on information from each thread's allocator?)

-Wyatt

On Thursday, 18 June 2015 at 15:43:10 UTC, Wyatt wrote:
> On Thursday, 18 June 2015 at 15:19:19 UTC, Etienne wrote:
>> On Thursday, 18 June 2015 at 15:09:46 UTC, Wyatt wrote:
>>> This comes to mind, along with the citations:
>>> http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/local-gc.pdf
>>>
>>> -Wyatt
>>
>> That's exactly what we're talking about, but we do the work that was done by the globalisation policy by using the `new shared` keyword.
>
> Maybe I misunderstood.  My interpretation was you were disallowing references from shared heap to local heap and
Exactly, unless you cast(shared) before you copy into the global heap - the local object must be kept trackable in the local heap or space. In any case, the shared is recursive and disallows this, so it's perfectly suitable to keep a shared GC consistent.

> obviating the whole globalisation problem.  No migrations; just explicit marking of global objects with "new shared". (Though I'm curious how you handle liveness of the global heap; it seems like that depends on information from each thread's allocator?)

The global heap and every thread will be scanned in stop the world setting just like the current GC. However, the idea is to use it less by making it exclusively for objects that were created with `new shared` `new immutable` `.idup` or `.sdup` (so that we can duplicate local objects into the shared GC conveniently)

In all of my security library (Botan) or TCP library (libasync) or even the vibe.d implementation at https://github.com/etcimon/vibe.d I haven't encountered a single instance of an object that was moved to another thread. The shared GC will be known to be very rarely useful.

On Thursday, 18 June 2015 at 15:09:46 UTC, Wyatt wrote:
> On Wednesday, 17 June 2015 at 22:21:21 UTC, Laeeth Isharc wrote:
>>
>> Do you have any links to reading material on this type of GC?
>>
> This comes to mind, along with the citations:
> http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/local-gc.pdf
>
> -Wyatt

Thank you.

Laeeth