Mac Apps That Use Garbage Collection Must Move to ARC

[Walter Bright via Digitalmars-d]

On 2/25/2015 4:50 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Feb 25, 2015 at 04:36:22PM -0800, Walter Bright via Digitalmars-d wrote:
>> On 2/25/2015 1:50 PM, deadalnix wrote:
>>> On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
>>>>> You seeing this completely one sided. Even if write barries make
>>>>> code slower by 10% its a non issue if the GC collections get faster
>>>>> by 10% as well. Then in average the program will run at the same
>>>>> speed.
>>>>
>>>> Hmmmm... not sure the math works out that way. -- Andrei
>>>
>>> Yeah the math are wrong, but the general idea remains.
>>>
>>> I don't think it make sens to completely discard the idea of
>>> barriers, especially when it come to write barrier on the immutable
>>> heap. At least that should certainly pay off.
>>
>> Part of the equation is D simply does not use GC anywhere near as
>> pervasively as Java does, so the benefit/cost is greatly reduced for
>> D.
>
> Do you have data to back that up?

I've written a Java compiler and and a GC for the Java VM (for Symantec, back in 
the 90's.). I'm familiar with the code generated for Java, and the code 
generated for D.

Yes, I'm pretty comfortable with the assessment of how often pointers are GC 
pointers and how often they are not.


> I don't know how typical this is, but in my own D code I tend to use
> arrays a lot, and they do tend to add significant GC load. A recent
> performance improvement attempt in one of my projects found that
> collection cycles take up to 40% of total running time (it's a CPU-bound
> process). Turning off GC collections and manually triggering them at
> strategic points with lower frequency gave me huge performance
> improvements, even though the collection cycles are still pretty slow.

Note that you didn't need write barriers for that.


> I'm not sure how write barriers would play into this scenario, though.
> The overall performance outside of GC collections would probably suffer
> a bit, but it might be more than made up for by more accurate collection
> cycles that take only a fraction of the time -- most of the scanned data
> is live, only a small subset needs to be collected. A generational GC
> would also greatly improve this particular use case, but that seems
> really remote in D right now.

Writing a generational collector for D is possible right now with no language 
changes, it's just that nobody has bothered to do it. Don't need write barriers 
for it, either.


 > In any case, a bit more investigation into
 > the actual costs/benefits of write barriers might give us more concrete
 > data to base decisions on, instead of just a blanket dismissal of the
 > whole idea.

Except that I've actually written GCs that used write barriers.

I've been there, done that. Of course, I might still be wrong. If you want to 
prove me wrong, do the work. You don't need compiler changes to prove yourself 
right, you can code in the write barriers explicitly.