Am 16.10.2013 21:05, schrieb Sean Kelly:
> On Oct 16, 2013, at 11:54 AM, Benjamin Thaut <code@benjamin-thaut.de> wrote:
>>
>> The problem is not that there are no GCs around in other languages which satisfy certain requirements. The problem is actually implementing them in D. I suggest that you read "The Garbage Collection Handbook" which explains this in deep detail. I'm currently reading it, and I might write an article about the entire D GC issue once I'm done with it.
>
> I think the short version is that D being able to directly call C code is a huge problem here.  Incremental GCs all rely on the GC being notified when pointers are changed.  We might be able to manage it for SafeD, but then SafeD would basically be its own language.
>

I think a even bigger problem are structs. Because if you need write barriers for pointers on the heap you are going to have a problem with structs. Because you will never know if they are located on the heap or the stack. Additionally making the stack percisely scannable and adding GC-Points will require a lot of compiler support. And even if this is doable in respect to DMD its going to be a big problem for GDC or LDC to change the codegen.

On Oct 16, 2013, at 1:05 PM, Benjamin Thaut <code@benjamin-thaut.de> wrote:
> 
> Am 16.10.2013 21:05, schrieb Sean Kelly:
>> On Oct 16, 2013, at 11:54 AM, Benjamin Thaut <code@benjamin-thaut.de> wrote:
>>> 
>>> The problem is not that there are no GCs around in other languages which satisfy certain requirements. The problem is actually implementing them in D. I suggest that you read "The Garbage Collection Handbook" which explains this in deep detail. I'm currently reading it, and I might write an article about the entire D GC issue once I'm done with it.
>> 
>> I think the short version is that D being able to directly call C code is a huge problem here.  Incremental GCs all rely on the GC being notified when pointers are changed.  We might be able to manage it for SafeD, but then SafeD would basically be its own language.
> 
> I think a even bigger problem are structs. Because if you need write barriers for pointers on the heap you are going to have a problem with structs. Because you will never know if they are located on the heap or the stack. Additionally making the stack percisely scannable and adding GC-Points will require a lot of compiler support. And even if this is doable in respect to DMD its going to be a big problem for GDC or LDC to change the codegen.

Yes, any pointer anywhere. I recall someone posting a doc about a compromise solution a few years back, but I'd have to do some digging to figure out what the approach was.

On Thursday, 17 October 2013 at 17:11:06 UTC, Sean Kelly wrote:
>> And even if this is doable in respect to DMD its going to be a big problem for GDC or LDC to change the codegen.
>
> Yes, any pointer anywhere. I recall someone posting a doc about a compromise solution a few years back, but I'd have to do some digging to figure out what the approach was.

LLVM actually comes with a quite expensive GC support infrastructure: http://llvm.org/docs/GarbageCollection.html. As far as I'm aware, it is not widely used in terms of the  "top-tier" LLVM projects, so there might be quite a bit of work involved in getting that to run.

David

Am 17.10.2013 19:16, schrieb David Nadlinger:
> On Thursday, 17 October 2013 at 17:11:06 UTC, Sean Kelly wrote:
>>> And even if this is doable in respect to DMD its going to be a big
>>> problem for GDC or LDC to change the codegen.
>>
>> Yes, any pointer anywhere. I recall someone posting a doc about a
>> compromise solution a few years back, but I'd have to do some digging
>> to figure out what the approach was.
>
> LLVM actually comes with a quite expensive GC support infrastructure:
> http://llvm.org/docs/GarbageCollection.html. As far as I'm aware, it is
> not widely used in terms of the "top-tier" LLVM projects, so there might
> be quite a bit of work involved in getting that to run.
>
> David

Uhhh, this sounds really good. They in fact have everything to implement a generational garbage collector. This would improve the D GC situation a lot.

But reading the part about the shadow stack really lowers my expectations. Thats really something you don't want. The performance impact is so going to be so big, that it doesn't make sense to use the better GC in the first place.

Kind Regards
Benjamin Thaut

On Thursday, 17 October 2013 at 17:28:17 UTC, Benjamin Thaut wrote:
> Am 17.10.2013 19:16, schrieb David Nadlinger:
>
> But reading the part about the shadow stack really lowers my expectations. Thats really something you don't want. The performance impact is so going to be so big, that it doesn't make sense to use the better GC in the first place.

There's always a tradeoff.  If an app is very delay-sensitive, then making the app run slower in general might be worthwhile if the delay could be eliminated.

Am 17.10.2013 19:47, schrieb Sean Kelly:
> On Thursday, 17 October 2013 at 17:28:17 UTC, Benjamin Thaut wrote:
>> Am 17.10.2013 19:16, schrieb David Nadlinger:
>>
>> But reading the part about the shadow stack really lowers my
>> expectations. Thats really something you don't want. The performance
>> impact is so going to be so big, that it doesn't make sense to use the
>> better GC in the first place.
>
> There's always a tradeoff.  If an app is very delay-sensitive, then
> making the app run slower in general might be worthwhile if the delay
> could be eliminated.

Well I just read it again, and it appears to me that the shadow stack is something they already have implemented and it can be used for "gc prototyping" but if you want you can write your own code generator plugin and generate your own stack maps. It actually sounds more feasable to implement a generational GC with LLVM then with what we have in dmd.

Kind Regards
Benjamin Thaut

On Thursday, 10 October 2013 at 00:02:09 UTC, Walter Bright wrote:
> Updated incorporating Steven's suggestion, and some comments about shared/const/mutable/purity.
>
> -------------------------------------------------------------
>
>     Adding Reference Counting to D
>

Automatic Reference Counting (ARC) as an alternative to D's Garbage Collector?

What is its state?

I think ARC is a very good direction.

Thanks.

Ref link:

https://wiki.dlang.org/Language_design_discussions#Automatic_Reference_Counting_.28ARC.29_as_an_alternative_to_D.27s_Garbage_Collector