Idea #1 on integrating RC with GC

[Paulo Pinto]

On Wednesday, 5 February 2014 at 09:05:02 UTC, Adam Wilson wrote:
> On Tue, 04 Feb 2014 23:38:54 -0800, Kagamin <spam at here.lot> 
> wrote:
>
>> 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?
>
> I've been asking myself those questions a lot over the past 
> couple days. If GC backed ARC is such a brilliant idea, how 
> come nobody has done it yet? I mean, it is a rather obvious 
> solution. What I am confident of is that it is going to create 
> a metric-ton of implementation gotchas for the compiler to sort 
> out (as if we don't have enough open trouble tickets already) 
> and it is going to pretty steeply increase the complexity of 
> language. I thought the whole point of D was to not be C++, 
> particularly in terms of complexity? All for a potentially 
> undeliverable promise of a little more speed and fewer (not 
> none) collection pauses.
>
> I have a suspicion that the reason that it hasn't been done is 
> that it doesn't actually improve the overall speed and quite 
> possibly reduces it. It will take months of engineering effort 
> just to ship the buggy initial functionality, and many more 
> months and possibly years to sort out all the edge cases. This 
> will in turn significantly reduce the bandwidth going towards 
> fixing the features we already have that don't work right and 
> improving the GC so that it isn't such an eyesore.

They have done it.

It is how the systems programming language Cedar, for the Mesa 
operating system at Xerox PARC used to work.

There are papers about it, that I already posted multiple times.

--
Paulo