On Thursday, 24 April 2014 at 14:15:45 UTC, Orvid King wrote:
> On Thursday, 24 April 2014 at 10:14:07 UTC, Kagamin wrote:
>> On Wednesday, 23 April 2014 at 18:35:26 UTC, Messenger wrote:
>>> On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote:
>>>> After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results?
>>>
>>> What is the state of Rainer Schütze's precise gc? Duplication of effort and all that.
>>
>> Also CDGC http://www.llucax.com.ar/proj/dgc/
>
> Ah, I hadn't realized he had actually implemented the concurrent GC he gave a talk on, I will make sure to look over the code before writing out the design. I was also planning on watching the full talk before posting the design, to make sure that it doesn't prevent any aspects of the design from working.

Leandro's CDGC is used as default GC in Sociomantic applications, so it is not only implemented but also extensively production-tested :) I have pinged him to give some feedback about issues he has encountered when trying to port it to D2.

On Thursday, 24 April 2014 at 07:09:27 UTC, Mike wrote:
> On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote:
>> After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results?
>
> What specific problems do you hope to solve with the new design?  Is it only to improve the speed at which the GC runs to completion on a single pass?  What about premptability so the GC could run as a low priority task, and be interrupted at any time to run something at a higher priority?  Is that out of scope?
>
> Mike

The goals of my design are to first off reduce the impact of the GC on D as a whole, I would love it if I could get it down to the same, or less impact as the MS.net GC. Secondly I want to make extending, or customizing the GC for each particular use-case significantly easier. Reducing the number of false positives would also be a good outcome. Overall I intend to significantly improve on D's current GC.

On Thursday, 24 April 2014 at 14:22:17 UTC, Dicebot wrote:
> On Thursday, 24 April 2014 at 14:15:45 UTC, Orvid King wrote:
>> Ah, I hadn't realized he had actually implemented the concurrent GC he gave a talk on, I will make sure to look over the code before writing out the design. I was also planning on watching the full talk before posting the design, to make sure that it doesn't prevent any aspects of the design from working.
>
> Leandro's CDGC is used as default GC in Sociomantic applications, so it is not only implemented but also extensively production-tested :) I have pinged him to give some feedback about issues he has encountered when trying to port it to D2.

In that case I'll have to take a much deeper look at it than I was originally planning, I will however definitely attempt to include a concurrent collection mode with my GC design, especially as there is already a well-tested version.

On Thursday, 24 April 2014 at 14:22:17 UTC, Dicebot wrote:
> On Thursday, 24 April 2014 at 14:15:45 UTC, Orvid King wrote:
>> On Thursday, 24 April 2014 at 10:14:07 UTC, Kagamin wrote:
>>> On Wednesday, 23 April 2014 at 18:35:26 UTC, Messenger wrote:
>>>> On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote:
>>>>> After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results?
>>>>
>>>> What is the state of Rainer Schütze's precise gc? Duplication of effort and all that.
>>>
>>> Also CDGC http://www.llucax.com.ar/proj/dgc/
>>
>> Ah, I hadn't realized he had actually implemented the concurrent GC he gave a talk on, I will make sure to look over the code before writing out the design. I was also planning on watching the full talk before posting the design, to make sure that it doesn't prevent any aspects of the design from working.
>
> Leandro's CDGC is used as default GC in Sociomantic applications, so it is not only implemented but also extensively production-tested :) I have pinged him to give some feedback about issues he has encountered when trying to port it to D2.

I didn't find any particular issues with the porting, I just didn't get far enough with the porting. My idea was to add patches on top of the current implementation instead of rolling out a complete new implementation from the scratch, since there were a few changes to the GC in D2, the porting should be done with a lot of care.

There is still also the problem with threading, see https://www.dsource.org/projects/tango/ticket/2087 for details.

BTW, if someone wants to take over the porting, and also do it "patch by patch" I recommend consulting this repo: http://git.llucax.com.ar/w/software/dgc/cdgc.git (here is where the complete history of the changes live, not in tango). And of course, feel free to contact me for any questions advice you might need!

On Thursday, 24 April 2014 at 14:15:45 UTC, Orvid King wrote:
> On Thursday, 24 April 2014 at 10:14:07 UTC, Kagamin wrote:
>> On Wednesday, 23 April 2014 at 18:35:26 UTC, Messenger wrote:
>>> On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote:
>>>> After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results?
>>>
>>> What is the state of Rainer Schütze's precise gc? Duplication of effort and all that.
>>
>> Also CDGC http://www.llucax.com.ar/proj/dgc/
>
> Ah, I hadn't realized he had actually implemented the concurrent GC he gave a talk on

Haha, you thought I was just inventing the numbers?!? :D

On Thursday, 24 April 2014 at 06:10:00 UTC, Rainer Schuetze wrote:
> On 23.04.2014 20:35, Messenger wrote:
>> What is the state of Rainer Schütze's precise gc? Duplication of effort
>> and all that.
>
> The implementation relies on correct RTInfo generation, but that still doesn't work as this pull request is sitting there for 8 months now without getting much review: https://github.com/D-Programming-Language/dmd/pull/2480

So this PR is the main blocker to a working heap-precise GC?

Given all of the talk and energy spent around the GC issue I'd have thought this would be on some super duper high priority fast path for inclusion. Nothing wrong with other GC projects but this seems like the lowest hanging fruit.

> Coincidentally, I updated the PR just a couple of days ago.
>
> The precise GC changes for druntime are here: https://github.com/rainers/druntime/tree/gcx_precise2

On Thursday, 24 April 2014 at 17:10:20 UTC, Brian Rogoff wrote:
>> The implementation relies on correct RTInfo generation, but that still doesn't work as this pull request is sitting there for 8 months now without getting much review: https://github.com/D-Programming-Language/dmd/pull/2480
>
> So this PR is the main blocker to a working heap-precise GC?
>
> Given all of the talk and energy spent around the GC issue I'd have thought this would be on some super duper high priority fast path for inclusion. Nothing wrong with other GC projects but this seems like the lowest hanging fruit.

Another issue is that in 64-bit address space precise GC gives no advantage as false pointers have low probability, so precise GC seems to be not worth the effort.

On Thursday, 24 April 2014 at 17:33:08 UTC, Kagamin wrote:
>
> Another issue is that in 64-bit address space precise GC gives no advantage as false pointers have low probability, so precise GC seems to be not worth the effort.

I disagree, in the current state of things there is benefit for 64 bit systems:
Currently there are many ways to accidentally allocate without the NO_SCAN flag for data without pointers.

The overhead of scanning this non-pointer data can often be significant enough to warrant hunting for mis-flagged allocations.

On Thursday, 24 April 2014 at 17:33:08 UTC, Kagamin wrote:
> Another issue is that in 64-bit address space precise GC gives no advantage as false pointers have low probability, so precise GC seems to be not worth the effort.

Except a precise gc is type-aware, no? And you could basically ask it to "please print out everything that you have currently allocated so I can debug what's allocating".

On Thursday, 24 April 2014 at 18:39:34 UTC, Messenger wrote:
> Except a precise gc is type-aware, no? And you could basically ask it to "please print out everything that you have currently allocated so I can debug what's allocating".

Depends on the implementation. One would want to not store data which doesn't help with collection - a pointers bitmask is enough for scanning, but not enough to know the type.