DIP60: @nogc attribute

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Fri Apr 18 13:21:34 PDT 2014


On 4/18/2014 10:53 AM, Andrei Alexandrescu wrote:
> On 4/18/14, 10:12 AM, Walter Bright wrote:
>> On 4/18/2014 8:34 AM, Andrei Alexandrescu wrote:
>>> Well there's been work on that. I mentioned this recent paper in this
>>> group:
>>> http://goo.gl/tavC1M, which claims RC backed by a cycle collector can
>>> reach
>>> parity with tracing. Worth a close read.
>>
>> A couple crucial points:
>>
>> 1. It achieves near parity with tracing, i.e. with a regular GC. It says
>> nothing about performance for regular pointer code, when those pointers
>> are replaced with ref counts.
>
> This is moving the goalposts. "Regular pointer code" is unsafe, and safety has
> been part of your past arguments. This is tracing GC compared to refcounting,
> cut and dried.

It applies equally to D arrays. Take a look at optimized array loops in D - the 
generated code is as good as C++ pointer style.


>> 2. It's a Java VM implementation. You can bet that the VM internally
>> isn't using ref counting - too slow.
>
> Not sure what this means in context.

Dogfood.


>> 3. I picked a GC for D because a GC coexists peacefully with pointers of
>> all types. This is not remotely true with ref counting. It's not an
>> issue with Java, which has no pointers, but this coexistence problem
>> would be a huge one for D.
>
> Agreed.

Phew! That's a fundamental point, and I'm glad we agree on it.



More information about the Digitalmars-d mailing list