Hacker News Reader

Comment by dilap | Hacker News Reader

ObjC, with automatic-reference-counting (and now Swift, I assume, though I haven't looked into it) is close to garbage collection, but has deterministic destruction.

The price you pay is you have to manually avoid cycles by annotating some references as weak.

It's a very nice scheme, actually.

View on HN

Thread-safe reference counting usually has lower throughput than tracing garbage collection. If it's throughput you're after, you're not going to get it with atomic reference counting.

OTOH refcounting has a more stable (and usually lower on average) memory usage, and no pauses (if cycles are ignored)

> and no pauses (if cycles are ignored)

Actually, even without cycles the destruction time is in general unbounded. Just think what happens when you allocate a very long linked list one element at a time and then drop the head. With a bit of ill luck or intention, you can make each element be allocated from a different page with enough different pages so that they fall out of the TLB. In that situation, even without having pages written out to disk, you can expect each element to take ~ a thousand cycles to free. On a million element list, that's ~500ms for freeing the head.

You can do reference counting asynchronously, though.

That specific issue exists in manual memory management schemes as well.

Spending the last month swapping between Swift and Clojure, there's still a very large safety difference between ARC & a memory-safe VM.

The problem is, compiler magic gives the illusion of safety, and then you segfault and remember that you're in a non-memory safe language. Swift is a big improvement, but it's still basically a DSL on top of objC, with all of the downsides that implies.

Question: If you use only strong and weak ptrs (no unsafe_unretained), avoid doing pointer arith, unchecked array accesss, or blowing the stack, can you still get segfaults? No, right?

If you stay in pure swift, it's much harder to segfault, but it's still possible, mainly due to the amount of objC code you interact with. Today, it's not reasonable to expect a swift programmer to be proficient without knowing objC, the way it's reasonable for a Java programmer to not know C.

The segfault I hit yesterday had to do with a CoreData API that didn't retained its argument, when I assumed it did. The bug doesn't appear when compiling with -Onone, but does appear in -O. Compiler flags are another place where Swift is still very much in C-land, rather than Java/Python/Ruby land. You still need to understand the C compilation model, and e.g. getting your ARC flags wrong in a cocoapod will still cause crashes.

To be clear, swift is a big improvement over objC, but you can't pretend it's a VM managed language.

> To be clear, swift is a big improvement over objC, but you can't pretend it's a VM managed language.

Memory safety does not require VM management (or so Rust is trying to prove).

>Memory safety does not require VM management (or so Rust is trying to prove).

I agree, with a few qualifications. I think Haskell has already proved it's possible.

I think Swift + ARC isn't a strong enough guarantee of memory safety for two reasons:

1) Swift has to interact with a huge amount of objC code, of varying degrees of quality (some Apple code, some OSS code via cocoapods). Swift itself would be much safer if all objC was rewritten in Swift.

2) ARC isn't as strong a guarantee as either GC or Rust's pointer semantics. For example, it's easy to hold weak references to something you thought was retained, and then dereference an invalid pointer.

So yes, you can have a memory safe language without a VM, but I think you need GC and/or much stronger pointer semantics, ala rust.

> I think Haskell has already proved it's possible.

Haskell has a GC, no?

Yes. GHC bundles a fairly heavy runtime with programs, including (but not limited to, not by a long shot) a garbage collector: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts

Yes. According to http://clang.llvm.org/docs/AutomaticReferenceCounting.html#s..., ARC assumes that self is valid for the lifetime of the call. This will not be the case if the last reference to the object is changed or cleared during the call, which may result a segfault. The performance loss of retaining and releasing self across all methods was deemed too much compared with the safety gains.

> and now Swift, I assume, though I haven't looked into it

Correct, Swift is built on top of the obj-c runtime (more or less) and also uses ARC.

Reply on news.ycombinator.com