Smart pointers instead of GC?

Adam Wilson flyboynw at gmail.com
Mon Feb 3 18:15:21 PST 2014


On Mon, 03 Feb 2014 17:54:22 -0800, Frustrated <c1514843 at drdrb.com> wrote:

> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
>> On Mon, 03 Feb 2014 17:04:08 -0800, Manu <turkeyman at gmail.com> wrote:
>>
>>> On 4 February 2014 06:21, Adam Wilson <flyboynw at gmail.com> wrote:
>>>
>>>> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu <
>>>> SeeWebsiteForEmail at erdani.org> wrote:
>>>>
>>>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>>>>
>>>>>> Anyone asking for the addition of ARC or owning pointers to D, gets
>>>>>> pretty much ignored. The topic is "Smart pointers instead of GC?",
>>>>>> remember? People here seem to be more interested in diverting to
>>>>>> nullable, scope and GC optimization. Telling, indeed.
>>>>>>
>>>>>
>>>>> I thought I made it clear that GC avoidance (which includes  
>>>>> considering
>>>>> built-in reference counting) is a major focus of 2014.
>>>>>
>>>>> Andrei
>>>>>
>>>>>
>>>> Andrei, I am sorry to report that anything other than complete  
>>>> removal of
>>>> the GC and replacement with compiler generated ARC will be  
>>>> unacceptable to
>>>> a certain, highly vocal, subset of D users. No arguments can be made  
>>>> to
>>>> otherwise, regardless of validity. As far as they are concerned the
>>>> discussion of ARC vs. GC is closed and decided. ARC is the only path
>>>> forward to the bright and glorious future of D. ARC most efficiently  
>>>> solves
>>>> all memory management problems ever encountered. Peer-Reviewed  
>>>> Research and
>>>> the Scientific Method be damned! ALL HAIL ARC!
>>>>
>>>> Sadly, although written as hyperbole, I feel that the above is fairly
>>>> close to the actual position of the ARC crowd.
>>>
>>>
>>> Don't be a dick.
>>> I get the impression you don't actually read my posts. And I also feel  
>>> like
>>> you're a lot more dogmatic about this than you think I am.
>>>
>>> I'm absolutely fine with GC in most applications, I really couldn't  
>>> give
>>> any shits if most people want a GC. I'm not dogmatic about it, and I've
>>> **honestly** tried to love the GC for years now.
>>> What I'm concerned about is that I have _no option_ to use D  
>>> uninhibited
>>> when I need to not have the GC.
>>>
>>> These are the problems:
>>> * GC stalls for long periods time at completely un-predictable moments.
>>> * GC stalls become longer *and* more frequent as memory becomes less
>>> available, and the working pool becomes larger (what a coincidence).
>>> * Memory footprint is unknowable, what if you don't have a virtual  
>>> memory
>>> manager? What if your total memory is measured in megabytes?
>>> * It's not possible to know when destruction of an object will happen,
>>> which has known workarounds (like in C#) but is also annoying in many
>>> cases, and supports the prior point.
>>>
>>> Conclusion:
>>>  GC is unfit for embedded systems. One of the most significant  
>>> remaining
>>> and compelling uses for a native systems language.
>>>
>>> The only realistic path I am aware of is to use ARC, which IS a form  
>>> of GC,
>>> and allows a lot more flexibility in the front-end.
>>> GC forces one very particular paradigm upon you.
>>> ARC is a GC, but it has some complex properties __which can be  
>>> addressed in
>>> various ways__. Unlike a GC which is entirely inflexible.
>>>
>>> You're not happy with ARC's cleaning objects up on the spot? Something  
>>> that
>>> many people WANT, but I understand zero cleanup times in the running
>>> context is in other occasions a strength of GC; fine, just stick the
>>> pointer on a dead list, and free it either later during idle time, or  
>>> on
>>> another thread. On the contrary, I haven't heard any proposal for a GC  
>>> that
>>> would allow it to operate in carefully controlled time-slices, or  
>>> strictly
>>> during idle-time.
>>> Cycles are a problem with ARC? True, how much effort are you willing to
>>> spend to mitigate the problem? None: run a secondary GC in the  
>>> background
>>> to collect cycles (yes, there is still a GC, but it has much less work  
>>> to
>>> do). Some: Disable background GC, manually require user specified weak
>>> references and stuff. Note: A user-preferred combination of the 2 could
>>> severely mitigate the workload of the background GC if it is still  
>>> desired
>>> to handle some complex situations, or user errors.
>>> Are there any other disadvantages to ARC? I don't know of them if  
>>> there are.
>>>
>>> Is far as I can tell, an ARC collector could provide identical  
>>> convenience
>>> as the existing GC for anyone that simply doesn't care. It would also  
>>> seem
>>> that it could provide significantly more options and control for those  
>>> that
>>> do.
>>>
>>> I am _yet to hear anyone present a realistic path forwards using any  
>>> form
>>> of GC_, so what else do I have to go with? Until I know of any other  
>>> path
>>> forward, I'll stand behind the only one I can see.
>>> You're just repeating "I don't care about something that a significant
>>> subset of D developers do care about, and I don't think any changes  
>>> should
>>> be made to support them".
>>> As far as I know, a switch to ARC could be done in a way that 'regular'
>>> users don't lose anything, or even notice... why is that so offensive?
>>
>> I am not trying to be a dick. But I do feel like a small number of  
>> people are trying to gang up on me for daring to point out that the  
>> solution they've proposed solution might have bigger problems for other  
>> people than they care to admit.
>>
>
> The problem is that you are selfish. You won't let anyone in the
> sand box to play with their toys... it's your sand box, even
> though it's not. It's your toys, even though it's not. You pitch
> a fit when someone comes into the sand box because you don't want
> them their. They might mess up the sand.
>
> Why can't you get it through your thick skull that just because
> people are suggesting alternative methods does not mean that you
> can't have your precious AGC? Also, why is it so difficult that
> just because you have no need for real-time applications that
> others don't either?
>
> Your method of thinking is very arrogant and I wish you the best
> of luck at the center of the universe... I hear it's a very
> unfriendly place.

Funny how you conveniently cut the thread immediately prior to paragraph  
where I say I would be all for supporting ARC side-by-side with the GC. It  
was only two paragraphs down, I can't imagine that it would've been that  
hard to include. I can only imagine that you left it off because it makes  
your name-calling look silly.

However I did point out that making ARC the DEFAULT is unlikely to ever  
happen. Walter has consistently refused to approve much smaller breaking  
changes in the past. Why would he all-of-a-sudden decide that now is the  
time for the biggest breaking change in the history of D? I am just  
pointing out that the creator of D is not likely to approve that pull  
request while he is still breathing. Please don't shoot the messenger.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator


More information about the Digitalmars-d mailing list