Idea #1 on integrating RC with GC

[Andrei Alexandrescu]

On 2/5/14, 4:57 PM, Adam D. Ruppe wrote:
> On Thursday, 6 February 2014 at 00:42:20 UTC, Andrei Alexandrescu wrote:
>> One other school of thought (to which I subscribe) is that one should
>> take advantage of reference counting where appropriate within a GC
>> milieu, regardless of more radical RC approaches that may be available.
>
> I agree with that stance, but I don't think there's a blanket rule
> there. I think RC freeing small slices will waste more time than it
> saves. Large allocations, on the other hand, might be worth it. So
> std.file.read for example returns a large block - that's a good
> candidate for refcounting since it might be accidentally subject to
> false pointers, or sit around too long creating needless memory
> pressure, etc.

That sounds reasonable. One possibility would be to define FreshSlice!T 
to mean this is a freshly-allocated slice; then it can be converted to a 
refcounted one or just a GC one.

> Anywho, I'd just go through on a case-by-case basis and tackle the big
> fish. Of course, a user could just do scope(exit) GC.free(ret); too.

That won't work because user code can't always know whether something 
received from the library had been freshly allocated or not.

>> Binding ref is also a related topic. All of these are complex matters,
>> and I think a few simple sketches don't do them justice.
>
> I'd rather discuss these details than adding RCSlice and toGC everywhere
> for more cost than benefit.

Have at it, of course. This is not constant sum, just don't hijack this 
discussion. I should warn you however we've been discussing this 
literally for years; your examples are just scratching the surface.


Andrei