On Wednesday, 17 June 2015 at 20:19:45 UTC, Laeeth Isharc wrote:
> On Wednesday, 17 June 2015 at 19:52:41 UTC, Etienne wrote:
> https://github.com/etcimon/druntime/commit/7da3939637bd1642400dbed83e3b0ff2844386ac
>>>>
>>>> Only error was with a signal handler trying to allocate on the GC. I think it'll be worth it for me to use this from now on. There's no locking and possibly no stop the world.
>>>
>>> why 'possibly' ?
>>
>> I hadn't tested it when I wrote that message. I committed the changes today and my tests were successful in a thread-local GC, however I'm still scanning the other thread contexts. The only limitation is that you can't move objects between threads, a pointer must remain in the thread that created it if the object is used in another thread.
>>
>> > https://github.com/etcimon/druntime/commit/78a2bca1356e0514c516e5261649ca0bf686b4cb
>
> I am no compiler/runtime guru, but it sounds like if it were possible to make this a swappable option for D this might be very important.  Is this true, and how much work is involved in making this industrial strength?

To me this is 100 times more stable simply because destructors can no longer be called from any thread. I'm also going to keep this implementation for its guarantee that destructors will be called. The absence of locking and stop the world makes it a very high performance GC.

Of course, the tradeoff is the absence of support in moving objects between threads. That's really an insignificant limitation compared to the above points. I don't expect it to be merged simply because nobody is familiar enough with this type of GC to have a say, except for what a GC shouldn't guarantee in general. And I'm really tired of people telling me what I can't or shouldn't do, when I'm brainstorming on this forum.

On Wednesday, 17 June 2015 at 21:28:46 UTC, rsw0x wrote:
> On Wednesday, 17 June 2015 at 20:19:45 UTC, Laeeth Isharc wrote:

>> I am no compiler/runtime guru, but it sounds like if it were possible to make this a swappable option for D this might be very important.  Is this true, and how much work is involved in making this industrial strength?
>
> that it falls apart as soon as you introduce any form of non-message passing threading and/or global variables?

you can't make a special section for shared memory and global variables without incurring very high performance costs under this apporach?

> if it was this easy, it would be done already.

I personally have found this to be a poor heuristic in life.

On Wednesday, 17 June 2015 at 21:35:34 UTC, Etienne wrote:

>> I am no compiler/runtime guru, but it sounds like if it were possible to make this a swappable option for D this might be very important.  Is this true, and how much work is involved in making this industrial strength?
>
> To me this is 100 times more stable simply because destructors can no longer be called from any thread. I'm also going to keep this implementation for its guarantee that destructors will be called. The absence of locking and stop the world makes it a very high performance GC.
>
> Of course, the tradeoff is the absence of support in moving objects between threads. That's really an insignificant limitation compared to the above points. I don't expect it to be merged simply because nobody is familiar enough with this type of GC to have a say, except for what a GC shouldn't guarantee in general. And I'm really tired of people telling me what I can't or shouldn't do, when I'm brainstorming on this forum.

Do you have any links to reading material on this type of GC?

I appreciate that it may in the general case be more stable, but in the particular implementation usually there is some distance to go from something good enough for personal use to something that others can depend on without having to understand the nitty gritty of the implementation.  So that is what I was asking...

On Wednesday, 17 June 2015 at 22:21:21 UTC, Laeeth Isharc wrote:
> On Wednesday, 17 June 2015 at 21:35:34 UTC, Etienne wrote:
>
>>> I am no compiler/runtime guru, but it sounds like if it were possible to make this a swappable option for D this might be very important.  Is this true, and how much work is involved in making this industrial strength?
>>
>> To me this is 100 times more stable simply because destructors can no longer be called from any thread. I'm also going to keep this implementation for its guarantee that destructors will be called. The absence of locking and stop the world makes it a very high performance GC.
>>
>> Of course, the tradeoff is the absence of support in moving objects between threads. That's really an insignificant limitation compared to the above points. I don't expect it to be merged simply because nobody is familiar enough with this type of GC to have a say, except for what a GC shouldn't guarantee in general. And I'm really tired of people telling me what I can't or shouldn't do, when I'm brainstorming on this forum.
>
> Do you have any links to reading material on this type of GC?
>
> I appreciate that it may in the general case be more stable, but in the particular implementation usually there is some distance to go from something good enough for personal use to something that others can depend on without having to understand the nitty gritty of the implementation.  So that is what I was asking...

No reading material. It's straightforward from my train of though, your object will be collected if it's not either in the immediate global namespace, in the current thread's stack, in the current thread's local namespace or in objects that were allocated in the current thread's GC.

People saying that this will fail in basic message-passing or multi-threading are right. If you move your object in another thread's object even though the other thread's object is in the global namespace, you can't expect it to be tracked by the thread-local GC.

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)

That's the "moving objects between threads" limitation I'm talking about. You need to use manual memory management and containers if you're going to use it for this purpose.

On Wednesday, 17 June 2015 at 22:35:13 UTC, Etienne Cimon wrote:
> On Wednesday, 17 June 2015 at 22:21:21 UTC, Laeeth Isharc wrote:
>> [...]
>
> No reading material. It's straightforward from my train of though, your object will be collected if it's not either in the immediate global namespace, in the current thread's stack, in the current thread's local namespace or in objects that were allocated in the current thread's GC.
>
> [...]

I think a shared GC should also be available, but only for objects created with `new shared`. We have an entire type system to support that.

On Thursday, 18 June 2015 at 00:54:35 UTC, Etienne wrote:
> On Wednesday, 17 June 2015 at 22:35:13 UTC, Etienne Cimon wrote:
>> On Wednesday, 17 June 2015 at 22:21:21 UTC, Laeeth Isharc wrote:
>>> [...]
>>
>> No reading material. It's straightforward from my train of though, your object will be collected if it's not either in the immediate global namespace, in the current thread's stack, in the current thread's local namespace or in objects that were allocated in the current thread's GC.
>>
>> [...]
>
> I think a shared GC should also be available, but only for objects created with `new shared`. We have an entire type system to support that.

Thank you for the colour.  Laeeth.

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?

Nim probably uses this sort of GC. Last I heard the plan was to introduce thread groups.

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.

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!

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...)