Disadvantages of ARC

[Sönke Ludwig]

Am 06.02.2014 14:35, schrieb Meta:
> On Thursday, 6 February 2014 at 13:23:14 UTC, Sönke Ludwig wrote:
>> Am 06.02.2014 12:37, schrieb Max Klyga:
>>> Anti-GC crowd tries to promote ARC as an deterministic alternative for
>>> memory management.
>>> I noticed that people promoting ARC do not provide any disadvantages for
>>> proposed approach.
>>>
>>> The thing is in gamedev and other soft-realitime software background
>>> only a handfull types of resources are really managed by RC and memory
>>> usage patterns are VERY specific to their domain (mostly linear
>>> allocation/deallocation and objects with non deterministic lifetime are
>>> preallocated in pools).
>>>
>>> Trying to use RC as a general method of memory management leads to some
>>> problems.
>>> A pretty detailed view by John Harrop (He is somewhat known for trolling
>>> in PL community, but nonetheless knows what he is talking about) -
>>> http://www.quora.com/Computer-Programming/How-do-reference-counting-and-garbage-collection-compare/answer/Jon-Harrop-1?srid=3Gvg&share=1#
>>>
>>>
>>>
>>> So RC could also introduce unpredictable pause times at undesired
>>> places.
>>>
>>> This is also confirmed by research from HP -
>>> http://www.hpl.hp.com/personal/Hans_Boehm/popl04/refcnt.pdf
>>>
>>> My point is that we should not ruin the language ease of use. We do need
>>> to deal with Phobos internal allocations, but we should not switch to
>>> ARC as a default memory management scheme. In practice people promoting
>>> ARC will probably not use phobos anyway. Currently its just an excuse to
>>> not use D.
>>>
>>> Look at c++ and STL, etc. People will roll their own solutions no matter
>>> what you try.
>>>
>>
>> Full ACK! Reference counting should be well supported, but it
>> shouldn't be the default scheme or built-in at a low level. From my
>> personal experience it would be ideal to be able to customize certain
>> types to be reference counted (allowing the user full flexibility
>> implementing the actual reference counting and without ruling out weak
>> references!), but have them accessible using the same syntax and type
>> conversion semantics as normal references.
>
> I think the best way forward would be to look at the places in D where
> allocations happen, and then figure out how we can optionally allow
> reference counting in these situations. Andrei just made a thread on
> this yesterday in regard to slices, which I think are the most promising
> for a RC solution.

I'm just not convinced (far from it) that Phobos should be built on top 
of such an RCSlice type. I rather strongly agree with Dicebot that the 
API should be extended to work with ranges or pre-allocated buffers 
where possible + support for custom allocators where it makes sense. How 
the memory is managed is then totally up to the user and no Phobos 
function needs to be aware of that (e.g. just pass in a pre-allocated, 
reference counted slice).