Disadvantages of ARC

[Paulo Pinto]

Am 06.02.2014 16:22, schrieb 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).

Although I seldom use D, I would like to say +1, if I may.

--
Paulo