On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
> On Mon, 03 Feb 2014 17:04:08 -0800, Manu <turkeyman@gmail.com> wrote:
>
>> On 4 February 2014 06:21, Adam Wilson <flyboynw@gmail.com> wrote:
>>
>>> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu <
>>> SeeWebsiteForEmail@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.

On Mon, 03 Feb 2014 17:48:42 -0800, NoUseForAName <no@spam.com> wrote:

> On Tuesday, 4 February 2014 at 00:49:04 UTC, Adam Wilson wrote:
>> On Mon, 03 Feb 2014 16:24:52 -0800, NoUseForAName <no@spam.com> wrote:
>>
> On Tuesday, 4 February 2014 at 00:49:04 UTC, Adam Wilson wrote:
>> That may be the case, but StackOverflow shows that ARC hasn't been panacea in Apple land either. Way to many people don't understand ARC and how to use it, and subsequently beg for help understanding heisenleaks and weak references.
>
> Your point? ARC addressed the latency issues, I never said it was without challenges of its own.
>
>> ARC places a higher cognitive load on the programmer than a GC does.
>
> Yes, it does. But the whole "not thinking about allocations" thing comes at the often unacceptable cost of unresponsive apps.
>

So basically, all programmers who use GC's are too stupid to understand ARC and should therefore either learn it because it is categorically superior, or face the ridicule of their superior brethren? A tad unrealistic there, most use a GC for purely practical reasons, namely their workload is such that without the benefit of not having to worry about memory they'd be even further behind, and subsequently spend even more time away from family and loved-ones.

>> And
>> Android runs just fine with GC'ed apps, but ARC guys don't want to talk about Google's successes there.
>
> Google's success there is that demanding apps are written using the NDK.
>

Fair enough.

>> Ahem. Wrong. See: WinForms, WPF, Silverlight. All extremely successful GUI toolkits that are not known for GC related problems.
>
> Silverlight is dead and was an utter failure. WinForms and WPF have an uncertain future. Neither has ever been used much in end user applications.
>

And how certain are you of this? Because that assertion doesn't match the data MS has collected.

> I would also like to say that the typical .NET or Java developer has lost all sense of what an efficient app feels like. E.g. someone who works with Eclipse all day will of course consider about everything else lightweight and snappy.
>

"I don't agree with their choices or preferences so they are wrong."

>> So that's why nearly every desktop app (for Windows at least, but that's the overwhelming majority) that started development since .NET came out is written C#?
>
> That is simply not true. The set of widely popular Windows desktop applications is basically .NET free. However, maybe you misunderstood me because - I admit - my phrasing was unclear. When I said "desktop" I meant end user desktop applications and games. Not enterprise/government desktop CRUD apps which are forced upon office workers who cannot reject them because of their horrible performance. I would not be surprised if most of those are indeed written in .NET (if not written in Java).
>

So now you're tightening your definition of desktop app to something you think you can win the argument on? Not a very powerful argument. I am using the industry standard definition: A desktop app is anything that runs on a desktop OS regardless of usage. Example, Visual Studio is both a .NET/WPF app AND a desktop app.

>> only something like 3% of all apps in the Windows Store are C++/CX.
>
> Does anybody actually use Windows Store? Frankly I do not know anyone who does.
>

LOL, I tend to agree, but that's a strawman, and besides the point. I was merely commenting on the code makeup of the Windows Store, not it's usage.

>> Server apps are written almost universally in .NET languages
>
> Eh.. yes. I said myself that Java and Java-likes rule that domain.
>
> Again, if D wants to compete with Java (or Microsoft's version of it) there is nothing wrong with GC.

D absolutely DOES want to get compete here, otherwise we might as well evict Andrei and Facebook right now.

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

On 2/3/2014 4:13 PM, H. S. Teoh wrote:
> I've seen real-life
> examples of ARCs gone horribly, horribly wrong, whereas had a GC been
> used in the first place things wouldn't have gone down that route.
>

I'm curious to hear more about this.

On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
> 1. RC imposes a time overhead on mutators in order to manipulate the counter.

Usually you just do a retain() when your thread attain ownership (at the root of the call tree). If you use embedded counters you most likely want the data in the cache anyway, but the cacheline is made dirty. So it cost you a write back. That affects reads of small objects more than writes.

(The C++ implementation does not use embedded counters.)

> 2. Both the counter manipulation and pointer load/store operations MUST be atomic to prevent races.

Not with transactional memory. You revert to locking, and you probably want that kind of synchronization anyway if you run multi threaded.

> 3. Naive RC turns read ops into store ops to update the count

If we assume naive RC, then we should assume naive GC.

> 4. No RC can reclaim cyclic data structures, which are much more common than is typically understood. [Bacon and Rajan 2001]

Weak pointers are sufficient to break cycles. You need a model, but you should have one anyway.

In cases where you build temporary data structures you can just avoid RC altogether and just use a pool, then free the entire pool.

> 5. Counter must be the same size as the pointer, which can result in significant overhead for small objects.

No? The counter must be able to hold the # of retain() calls.

> 6. RC can still pause. When the last head to a large pointer structure is deleted, RC MUST delete each descendant node.

Not really, you can postpone the deletion by pushing it onto a queue. The free it not by node at your own leisure...

> Note that these are paraphrases of the book, not me talking. And these apply equally to ARC and vanilla RC.

You don't  use RC alone, you use it with fully owned pointers, region pools, etc.

GC is simpler and more uniform, and that's it.

On Mon, 03 Feb 2014 17:54:22 -0800, Frustrated <c1514843@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@gmail.com> wrote:
>>
>>> On 4 February 2014 06:21, Adam Wilson <flyboynw@gmail.com> wrote:
>>>
>>>> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu <
>>>> SeeWebsiteForEmail@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

On Mon, 03 Feb 2014 18:14:36 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
>> 1. RC imposes a time overhead on mutators in order to manipulate the counter.
>
> Usually you just do a retain() when your thread attain ownership (at the root of the call tree). If you use embedded counters you most likely want the data in the cache anyway, but the cacheline is made dirty. So it cost you a write back. That affects reads of small objects more than writes.
>
> (The C++ implementation does not use embedded counters.)
>
>> 2. Both the counter manipulation and pointer load/store operations MUST be atomic to prevent races.
>
> Not with transactional memory. You revert to locking, and you probably want that kind of synchronization anyway if you run multi threaded.
>
>> 3. Naive RC turns read ops into store ops to update the count
>
> If we assume naive RC, then we should assume naive GC.
>

Indeed D is a naive GC, but that's not the point. Naive RC incurs a penalty that even Naive GC's don't.

>> 4. No RC can reclaim cyclic data structures, which are much more common than is typically understood. [Bacon and Rajan 2001]
>
> Weak pointers are sufficient to break cycles. You need a model, but you should have one anyway.
>

Yes, they absolutely are. However, supporting them at the automatic level requires adding keywords to the language. If ARC is made the default in D you will automatically have memory leaks where before you did not, and programmer will have to carefully scan the code by hand to find everything that needs to be marked with a 'weak' keyword. It's an extremely frustrating and error-prone process. The compiler cannot detect cyclic-refs, it's a halting problem.

> In cases where you build temporary data structures you can just avoid RC altogether and just use a pool, then free the entire pool.
>
>> 5. Counter must be the same size as the pointer, which can result in significant overhead for small objects.
>
> No? The counter must be able to hold the # of retain() calls.
>

Yes, which can theoretically be as many as a 64-bit integer. In a systems language you have to design for what is possible, not merely likely. Because someday, some nutcase, somewhere is going to overflow the counter, and given that it's hidden by the compiler, will be VERY tricky to figure out. And he will have a perfectly rational reason for doing so.

>> 6. RC can still pause. When the last head to a large pointer structure is deleted, RC MUST delete each descendant node.
>
> Not really, you can postpone the deletion by pushing it onto a queue. The free it not by node at your own leisure...
>

The GC Handbook deals with that idea directly: "Unfortunately, this technique allows large garbage structures to be hidden by smaller ones, and hence increases overall space requirements. [Boehm, 2004]" - The Garbage Collection Handbook

>> Note that these are paraphrases of the book, not me talking. And these apply equally to ARC and vanilla RC.
>
> You don't  use RC alone, you use it with fully owned pointers, region pools, etc.
>
> GC is simpler and more uniform, and that's it.

That may be "it", but it's a pretty big "it". Simplicity and uniformity are VERY important.

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

On Mon, 03 Feb 2014 18:14:36 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
>> 1. RC imposes a time overhead on mutators in order to manipulate the counter.
>
> Usually you just do a retain() when your thread attain ownership (at the root of the call tree). If you use embedded counters you most likely want the data in the cache anyway, but the cacheline is made dirty. So it cost you a write back. That affects reads of small objects more than writes.
>
> (The C++ implementation does not use embedded counters.)
>

There are many more ways to modify the count than a thread.

>> 2. Both the counter manipulation and pointer load/store operations MUST be atomic to prevent races.
>
> Not with transactional memory. You revert to locking, and you probably want that kind of synchronization anyway if you run multi threaded.
>

Transactional memory incurs a massive perf penalty beyond even what a lock would. You might be able to do better than a lock with Intel's TSX, but that is brand new, available on Haswells only, and even then only the high-end models. I doubt you'll be able to sell TM-ARC to perf conscience users as the perf will most likely be much worse than a GC for the next decade.


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

On 2/3/14, 2:51 PM, Frank Bauer wrote:
> I'm not quite sure that I understand what you mean by GC avoidance being
> a major focus of 2014 though. In the long term, can I look forward to
> writing an absolutely, like in 100 %, like in guaranteed, GC free D app
> with all of current D's and Phobos' features if I choose to? Or does it
> mean: well for the most part it will avoid the GC, but if you're unlucky
> the GC might still kick in if you don't pay attention and when you least
> expect it?

Depends on how we (including YOU) design it.

Andrei

On 2/3/14, 3:13 PM, woh wrote:
>
>   Any system that forces a single way of handling memory as the only
> viable method, be it GC( as D currently does), or ARC, is undesirable to me
>
>    Rust seems to have found a very nice model, and even cpp with
> value/unique/rc/weak is IMO superior to what D currently offers

I think Rust expended too much language complexity on that one issue.

Andrei

On 2/3/14, 4:49 PM, Adam Wilson wrote:
> That may be the case, but StackOverflow shows that ARC hasn't been
> panacea in Apple land either. Way to many people don't understand ARC
> and how to use it, and subsequently beg for help understanding
> heisenleaks and weak references. ARC places a higher cognitive load on
> the programmer than a GC does. And Android runs just fine with GC'ed
> apps, but ARC guys don't want to talk about Google's successes there.

Links please.

Andrei