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).
