On 4/22/2014 12:42 PM, Michel Fortin wrote:
> On 2014-04-22 19:02:05 +0000, Walter Bright <newshound2@digitalmars.com> said:
>
>> Memory safety is not a strawman. It's a critical feature for a modern
>> language, and will become ever more important.
>
> What you don't seem to get is that ARC, by itself, is memory-safe.

I repeatedly said that it is not memory safe because you must employ escapes from it to get performance.


> Objective-C isn't memory safe because it lets you play with raw pointers too. If
> you limit yourself to ARC-managed pointers (and avoid undefined behaviours
> inherited from C) everything is perfectly memory safe.

Allow me to make it clear that IF you never convert an ARC reference to a raw pointer in userland, I agree that it is memory safe. But this is not practical for high performance code.


> I'm pretty confident that had I continued my work on D/Objective-C we'd now be
> able to interact with Objective-C objects using ARC in @safe code. I was
> planning for that. Objective-C actually isn't very far from memory safety now
> that it has ARC, it just lacks the @safe attribute to enable compiler verification.

I wish you would continue that work!

On 4/22/2014 4:00 AM, Don wrote:
> It turns out to have enormous value. I will explain this in my DConf talk. A
> little preview:
> Almost all of our code at Sociomantic obeys this behaviour, and it's probably
> the most striking feature of our codebase. By "almost all" I mean probably 90%
> of our code, including all of our libraries. Not just the 5% - 10% that could
> marked as @nogc according to your DIP.
>
> The key property it ensures is, if you make N calls to the function, the number
> of GC allocations is in O(1). We don't care if makes 0 allocations or 17.

I don't really understand how dicebot's proposal ensures this property. I guess it'll have to wait until Dconf!

> We're not really interested in whether a function uses the GC or not, since most
> interesting functions do need to do some memory allocation.
>
> Ideally, we'd want an attribute which could applied to *all* of Phobos, except
> for some convenience functions. We have no interest in library code which
> doesn't behave in that way.

On 23/04/14 06:33, Walter Bright wrote:

> I repeatedly said that it is not memory safe because you must employ
> escapes from it to get performance.

Apparently you need that for the GC as well, that's why this thread was started to begin with.

-- 
/Jacob Carlborg

On 22/04/14 20:48, Steven Schveighoffer wrote:

> I mean not like I can't because I don't want to or don't have time, but
> can't as in I lack the skill set :) It's interesting to debate, and I
> get the concepts, but I am not a CPU/cache guy, and these things are
> really important to get right for performance, since ref counting would
> be used frequently.

That's the worst kind of excuses :) I don't remember the last time I started working on a project and know what I was doing/had the right skill set. I mean, that's how you learn.

-- 
/Jacob Carlborg

On 22 April 2014 05:03, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 4/21/2014 10:57 AM, Steven Schveighoffer wrote:
>>
>> On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
>> <newshound2@digitalmars.com>
>> wrote:
>>
>>> On 4/21/2014 5:00 AM, Steven Schveighoffer wrote:
>>>>>
>>>>> Total replacement of GC with ARC in D will:
>>>>
>>>> This is the wrong straw-man, I'm not advocating for this at all.
>>>
>>>
>>> Many are when they advocate ARC for D.
>>
>>
>> Does that preclude you from accepting any kind of ARC for D?
>
>
> No. My objection is to pervasive ARC, i.e. all gc is replaced with ARC, and it all magically works.

It's not magic, it's careful engineering, and considering each problem case one by one as they arise until it's good.


>>> 5. Numerous posters here have posited that the overhead of ARC can be eliminated with a sufficiently smart compiler (which does not exist).
>>
>>
>> You continue to speak in extremes. People are saying that the compiler can eliminate most of the needless ARC increments and decrements, not all of them.
>
>
> Manu, for example, suggests it is good enough to make the overhead insignificant. I'm skeptical.

I didn't quite say that, but let me justify that claim if you want to put it in those words.

RC fiddling in low-frequency code is insignificant.
High-frequency code doesn't typically allocate, and is also likely to
implement a context specific solution anyway if it is truly
performance sensitive.
In the event of code where RC fiddling is found to make a significant
impact on performance, there are various tools available to address
this directly.

There's a middle-ground that might suffer compared to GC; moderate-frequency, where code is sloppily written doing whatever it likes without any real care, and run lots of iterations. But that's not usually an example of performance sensitive code, it's just crappy code run many times, and again, they have the tools to improve it easily if they care enough to do so.

I also believe programmers will learn the performance characteristics of ARC very quickly, and work with it effectively. The core of my argument is that it's _possible_ to work with ARC, it's not possible to work with GC if it is fundamentally incompatible with your application.


>> Compilers that do this do exist.
>
>
> I can't reconcile agreeing that ARC isn't good enough to be pervasive with compiler technology eliminates unnecessary ARC overhead.

The most important elimination is objects being passed down a
call-tree via args. That can certainly eliminate properly.
High-frequency code always exists nearer to the leaves.
D has pure (which is definitely well employed), and 'shared' is an
explicit attribute, which allows the compiler to make way more
assumptions than O-C.

The ARC optimisations are predictable and reliable. The suggestion that acceptable code performance relying on specific optimisation is a concept you can't reconcile is a bit strange. Programmers rely on optimisation all the time for acceptable performance. This is no different.

Manu, you obviously believe in ARC. I've made an attempt to do ARC, detailed in the other thread here. I failed.

http://forum.dlang.org/thread/l34lei$255v$1@digitalmars.com

Michel Fortin also wants to bring iOS ARC to D.

I suggest you get together with Michel and work out a detailed design, and propose it.

On 23 April 2014 04:28, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
>>>
>>> On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright
>>> <newshound2@digitalmars.com>
>>> wrote:
>>>>
>>>> The thing is, with iOS ARC, it cannot be statically guaranteed to be memory safe.
>>>
>>>
>>> So?
>>
>>
>> If you see no value in static guarantees of memory safety, then what can I say?
>
>
> Seriously, the straw man arguments have to stop.
>
> There is plenty of valuable D code that is not guaranteed memory safe. For example, druntime.
>
> ARC does not equal guaranteed memory safety. So NO, it cannot replace the GC for D @safe code. That doesn't make it useless.

Why not? Assuming that direct access to the refcount is not @safe, why would ARC be unsafe? What makes it less safe than the GC?

On Tuesday, 22 April 2014 at 19:42:20 UTC, Michel Fortin wrote:
> Objective-C isn't memory safe because it lets you play with raw pointers too. If you limit yourself to ARC-managed pointers (and avoid undefined behaviours inherited from C) everything is perfectly memory safe.

I'm not convinced that it is safe in multi-threaded mode. How does ARC deal with parallell reads and writes from two different threads? IIRC the most common implementations deals with read/read and write/write, but read/write is too costly?

On 23/04/14 10:31, Walter Bright wrote:
> Manu, you obviously believe in ARC. I've made an attempt to do ARC,
> detailed in the other thread here. I failed.
>
> http://forum.dlang.org/thread/l34lei$255v$1@digitalmars.com

That conversation started out from the D/Objective-C conversations. To have ARC in D and be compatible with the one in Objective-C you don't have many choices. I'm not sure but I don't think your proposal was not compatible with ARC in Objective-C.

-- 
/Jacob Carlborg

On 2014-04-23 09:50:57 +0000, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com> said:

> On Tuesday, 22 April 2014 at 19:42:20 UTC, Michel Fortin wrote:
>> Objective-C isn't memory safe because it lets you play with raw pointers too. If you limit yourself to ARC-managed pointers (and avoid undefined behaviours inherited from C) everything is perfectly memory safe.
> 
> I'm not convinced that it is safe in multi-threaded mode. How does ARC deal with parallell reads and writes from two different threads? IIRC the most common implementations deals with read/read and write/write, but read/write is too costly?

The answer is that in the general case you should protect reads and writes to an ARC pointer with locks. Otherwise the counter risk being getting out of sync and later you'll get corruption somewhere.

There are atomic properties which are safe to read and write from multiple threads. Internally they use the @synchronized keyword on the object.

But since there's no 'shared' attribute in Objective-C, you can't go very far if you wanted the compiler to check things for memory safety. That said, if you assume a correct implementation of the NSCopying protocol (deep copying), objects following that protocol would be safe to pass through a std.concurrency-like interface.

In all honesty, I'm not that impressed with the multithreading protections in D either. It seems you so often have to bypass the type system to make something useful that it doesn't appear very different from not having them. And don't get me started with synchronized classes...

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca