On Wednesday, 5 February 2014 at 01:52:48 UTC, Adam Wilson wrote:
> On Tue, 04 Feb 2014 17:12:37 -0800, deadalnix <deadalnix@gmail.com> wrote:
>
>> On Tuesday, 4 February 2014 at 23:51:35 UTC, Andrei Alexandrescu wrote:
>>> Consider we add a library slice type called RCSlice!T. It would have the same primitives as T[] but would use reference counting through and through. When the last reference count is gone, the buffer underlying the slice is freed. The underlying allocator will be the GC allocator.
>>>
>>> Now, what if someone doesn't care about the whole RC thing and aims at convenience? There would be a method .toGC that just detaches the slice and disables the reference counter (e.g. by setting it to uint.max/2 or whatever).
>>>
>>> Then people who want reference counting say
>>>
>>> auto x = fun();
>>>
>>> and those who don't care say:
>>>
>>> auto x = fun().toGC();
>>>
>>>
>>> Destroy.
>>>
>>> Andrei
>>
>> RC need GC to collect loops. So you want to have the GC at the lowest level.
>>
>> That being understood, I'd rather connect things the other way around.
>>
>> auto x = foo();
>> auto x = foo().toRC();
>
> The ARC crowd is going to hate this because it's still a GC allocation then you hook it to RC. So they can still have random GC pauses.

GC.disable. Just saying.

On Tue, 04 Feb 2014 18:08:32 -0800, Sean Kelly <sean@invisibleduck.org> wrote:

> On Wednesday, 5 February 2014 at 01:52:48 UTC, Adam Wilson wrote:
>> On Tue, 04 Feb 2014 17:12:37 -0800, deadalnix <deadalnix@gmail.com> wrote:
>>
>>> On Tuesday, 4 February 2014 at 23:51:35 UTC, Andrei Alexandrescu wrote:
>>>> Consider we add a library slice type called RCSlice!T. It would have the same primitives as T[] but would use reference counting through and through. When the last reference count is gone, the buffer underlying the slice is freed. The underlying allocator will be the GC allocator.
>>>>
>>>> Now, what if someone doesn't care about the whole RC thing and aims at convenience? There would be a method .toGC that just detaches the slice and disables the reference counter (e.g. by setting it to uint.max/2 or whatever).
>>>>
>>>> Then people who want reference counting say
>>>>
>>>> auto x = fun();
>>>>
>>>> and those who don't care say:
>>>>
>>>> auto x = fun().toGC();
>>>>
>>>>
>>>> Destroy.
>>>>
>>>> Andrei
>>>
>>> RC need GC to collect loops. So you want to have the GC at the lowest level.
>>>
>>> That being understood, I'd rather connect things the other way around.
>>>
>>> auto x = foo();
>>> auto x = foo().toRC();
>>
>> The ARC crowd is going to hate this because it's still a GC allocation then you hook it to RC. So they can still have random GC pauses.
>
> GC.disable. Just saying.

Hmm, as long as it doesn't disable the allocation that might just work.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On 2/4/14, 4:01 PM, Steven Schveighoffer wrote:
> On Tue, 04 Feb 2014 18:51:35 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Consider we add a library slice type called RCSlice!T. It would have
>> the same primitives as T[] but would use reference counting through
>> and through. When the last reference count is gone, the buffer
>> underlying the slice is freed. The underlying allocator will be the GC
>> allocator.
>
> Doesn't that mean it lives in the GC heap and is scanned along with all
> the other data in the GC heap (and triggers GC cycles)? What is the
> benefit?

GC.free is the benefit.

> Shouldn't the default be what is expected now? That is, I don't want to
> have to change all my code to return RCSlice!T instead of T[]. I admit,
> I don't know how that would work...

Me neither.


Andrei

On 2/4/14, 4:07 PM, Adam Wilson wrote:
> I am assuming that you ignoring cyclic-refs for now.

The GC will lift cycles.

> Second thought. Why is their an extra step for those of us who don't
> want the GC.

The flow goes from RC to losing RC and relying on GC. You can't add RC to some arbitrary allocation safely.


Andrei

On 2/4/14, 5:12 PM, deadalnix wrote:
> On Tuesday, 4 February 2014 at 23:51:35 UTC, Andrei Alexandrescu wrote:
>> Consider we add a library slice type called RCSlice!T. It would have
>> the same primitives as T[] but would use reference counting through
>> and through. When the last reference count is gone, the buffer
>> underlying the slice is freed. The underlying allocator will be the GC
>> allocator.
>>
>> Now, what if someone doesn't care about the whole RC thing and aims at
>> convenience? There would be a method .toGC that just detaches the
>> slice and disables the reference counter (e.g. by setting it to
>> uint.max/2 or whatever).
>>
>> Then people who want reference counting say
>>
>> auto x = fun();
>>
>> and those who don't care say:
>>
>> auto x = fun().toGC();
>>
>>
>> Destroy.
>>
>> Andrei
>
> RC need GC to collect loops. So you want to have the GC at the lowest
> level.

Correctamundo.

> That being understood, I'd rather connect things the other way around.
>
> auto x = foo();
> auto x = foo().toRC();

I don't know how to implement that.


Andrei

On 2/4/14, 5:06 PM, Adam Wilson wrote:
> Ok, disregard my previous post. I think I understand better what Andrei
> is driving at, but it's not obvious, better examples are needed. But
> more to the point this is going to make us all equally miserable. The
> ARC guys don't get the compiler support needed to make ARC fast.

Of course they could. Compiler can have internal support for RC slices. Object will need some built-in support anyway.

> It
> completely ignores cyclic-refs inside the slice.

Wrong. It leaves cyclic references to the GC.

> It doesn't solve the
> primary ARC-camp complaint about the reliance on the GC.

Why not?

> The GC now guys
> have more hoops to jump-through when working with Phobos.

Why?

> And it
> increases complexity and cognitive load all around.

That comes with the territory. Have no illusion we can add RC support in any way at no cost.


Andrei

On Tue, 04 Feb 2014 20:21:17 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/4/14, 5:06 PM, Adam Wilson wrote:
>> Ok, disregard my previous post. I think I understand better what Andrei
>> is driving at, but it's not obvious, better examples are needed. But
>> more to the point this is going to make us all equally miserable. The
>> ARC guys don't get the compiler support needed to make ARC fast.
>
> Of course they could. Compiler can have internal support for RC slices. Object will need some built-in support anyway.
>
>> It
>> completely ignores cyclic-refs inside the slice.
>
> Wrong. It leaves cyclic references to the GC.
>

Ok, I can see that.

>> It doesn't solve the
>> primary ARC-camp complaint about the reliance on the GC.
>
> Why not?
>

It still has to be loaded and running. It can still non-deterministically pause. Yes, the pause may happen less often but they will take a similar amount of time to run the mark phase as the current, which is statistically the longest phase.

I already know that they are going to complain loudly because this does nothing to resolve their central complaint. Also Adam Ruppe brought up an interesting problem that I didn't understand with slicing in this configuration. If he could comment that would be appreciated.

>> The GC now guys
>> have more hoops to jump-through when working with Phobos.
>
> Why?
>

New details to corral: Don't forget to add your .toGC() calls now kids!

>> And it
>> increases complexity and cognitive load all around.
>
> That comes with the territory. Have no illusion we can add RC support in any way at no cost.
>

Yes, but why do it in such a way as to penalize existing practices. The penalty properly belongs on the new practices.

>
> Andrei
>


-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Tuesday, 4 February 2014 at 23:51:35 UTC, Andrei Alexandrescu wrote:
> and those who don't care say:
>
> auto x = fun().toGC();

If I don't care, why would I place .toGC() at the end of my calls? What reason do I have to go out of my way to request this? What problems can I expect when I forget to add it?

On 2/4/14, 11:20 PM, Jesse Phillips wrote:
> On Tuesday, 4 February 2014 at 23:51:35 UTC, Andrei Alexandrescu wrote:
>> and those who don't care say:
>>
>> auto x = fun().toGC();
>
> If I don't care, why would I place .toGC() at the end of my calls?

This is the way it all works: RC+GC is more structure than GC, so you start with more structure and then optionally "forget" it.

> What
> reason do I have to go out of my way to request this?

You use an API that uses e.g. string, not RCString.

> What problems can
> I expect when I forget to add it?

Passing x around won't compile.


Andrei

My understanding was that ARC completely replaces GC and everything including slices becomes refcounted. Is having mixed incompatible GC and ARC code and trying to get them interoperate a good idea? Can you sell such mixed code to ARC guys?