I've been trying to think of a solution to use over here at Remedy for making the garbage collector reference count allocations instead of the current scan method (even with Rainer Schütze's GC it still does a scan, and I'd feel much more comfortable not having to schedule a GC collection somewhere in our update loop).

I've totally missed the other threads on reference counting, but should reference counting be a part of some library that you can optionally use or should the garbage collector hide all that from you?

My thinking on the subject is that you only need one additional function added to the garbage collector that handles pointer assignments. The parameters are a ref to the pointer you're assigning to, and the new pointer. The GC would then decrement the reference count for the memory referenced by the pointer you're assigning to, and increment the reference count fr the new memory referenced.

This, I imagine, would fit neatly in with slices and classes equally. It would also be optional - the current default GC wouldn't do anything with the function and . The downside is that a pointer assign would invoke a GC call and that it would still need to deal with circular dependencies in some fashion (however dealing with that at an allocation level rather than a class level seems potentially less problematic to me).

If this is beyond the scope of this thread, I'll start up a new one to discuss all the potential pitfalls and problems that could be encountered. I haven't had any time to actually do research in to it or trial it yet.

On Tuesday, 13 May 2014 at 15:14:16 UTC, Andrei Alexandrescu wrote:
> On 5/13/14, 6:43 AM, Dicebot wrote:
>> On actual topic of next step - I agree with Jacob, removing all
>> internal allocations from Phobos is most beneficial short-term
>> goal.
>
> That's a given. This task and improving RC don't compete (except, of course, for bearing on the same people). I ask again, who wants to champion std.refcounted? Rainer? Manu? Michel? Are you there? -- Andrei

You should start with at least some sort of design document for what such module should look like. Right now it is not clear to me at all what kind of improvements are desired within current language limits.

On 5/15/14, 6:02 AM, Dicebot wrote:
> On Tuesday, 13 May 2014 at 15:14:16 UTC, Andrei Alexandrescu wrote:
>> On 5/13/14, 6:43 AM, Dicebot wrote:
>>> On actual topic of next step - I agree with Jacob, removing all
>>> internal allocations from Phobos is most beneficial short-term
>>> goal.
>>
>> That's a given. This task and improving RC don't compete (except, of
>> course, for bearing on the same people). I ask again, who wants to
>> champion std.refcounted? Rainer? Manu? Michel? Are you there? -- Andrei
>
> You should start with at least some sort of design document for what
> such module should look like.

The design is part of the championing. But haven't heard a peep - it seems everybody wants to go to heaven, but nobody wants to die :o).

> Right now it is not clear to me at all
> what kind of improvements are desired within current language limits.

The clarify it to yourself and others. Start with a library approach to making reference counting easy and convenient. Then see how it informs possible language improvements.


Andrei

On Thursday, 15 May 2014 at 15:46:13 UTC, Andrei Alexandrescu wrote:
> On 5/15/14, 6:02 AM, Dicebot wrote:
>> On Tuesday, 13 May 2014 at 15:14:16 UTC, Andrei Alexandrescu wrote:
>>> On 5/13/14, 6:43 AM, Dicebot wrote:
>>>> On actual topic of next step - I agree with Jacob, removing all
>>>> internal allocations from Phobos is most beneficial short-term
>>>> goal.
>>>
>>> That's a given. This task and improving RC don't compete (except, of
>>> course, for bearing on the same people). I ask again, who wants to
>>> champion std.refcounted? Rainer? Manu? Michel? Are you there? -- Andrei
>>
>> You should start with at least some sort of design document for what
>> such module should look like.
>
> The design is part of the championing. But haven't heard a peep - it seems everybody wants to go to heaven, but nobody wants to die :o).
>
>> Right now it is not clear to me at all
>> what kind of improvements are desired within current language limits.
>
> The clarify it to yourself and others. Start with a library approach to making reference counting easy and convenient. Then see how it informs possible language improvements.

Well I have already pointed out my concerns in this thread. Until some solution is found new refcount module doesn't seem worth putting the effort into.