Disadvantages of ARC

[Sönke Ludwig]

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.