4 ms·

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 destruc

by dilap 12y ago

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.

masklinn 12y ago
> 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.
pcwalton 12y ago
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.
- masklinn 12y ago
  OTOH refcounting has a more stable (and usually lower on average) memory usage, and no pauses (if cycles are ignored)
  - Tuna-Fish 12y ago
    > 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.
    - TheLoneWolfling 12y ago
      You can do reference counting asynchronously, though.
    - masklinn 12y ago
      That specific issue exists in manual memory management schemes as well.
arohner 12y ago
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.
- dilap 12y ago
  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?
  - arohner 12y ago
    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.
    - masklinn 12y ago
      > 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).
      - arohner 12y ago
        >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.

by dilap 12y ago

masklinn 12y ago

> 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.

pcwalton 12y ago

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.

masklinn 12y ago
OTOH refcounting has a more stable (and usually lower on average) memory usage, and no pauses (if cycles are ignored)
- Tuna-Fish 12y ago
  > 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.
  - TheLoneWolfling 12y ago
    You can do reference counting asynchronously, though.
  - masklinn 12y ago
    That specific issue exists in manual memory management schemes as well.

arohner 12y ago

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.

dilap 12y ago
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?
- arohner 12y ago
  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.
  - masklinn 12y ago
    > 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).
    - arohner 12y ago
      >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.