4

I know that the biggest difference between GC and ARC is that GC is run time process while ARC is operates in compile time. So when working with ARC the developer need to take care of memory in some scenarios.

How ever according to this, there is no place left for developer interaction in SWFT memory management architecture.

So how they do this? Do they have a run time process for cleaning up the memory, or there some thing else?

Binarian
  • 12,296
  • 8
  • 53
  • 84
Ilya Gazman
  • 31,250
  • 24
  • 137
  • 216
  • 1
    As Swift is not open source, I am doubtful whether anyone will be able to give a good answer. – Chuck Jun 03 '14 at 15:33
  • what do you mean by "working with ARC the developer need to take care of memory in some scenarios"? Swift have no difference. You still need to worry about retain-cycle and use `weak` to break it – Bryan Chen Jun 05 '14 at 06:14

3 Answers3

5

Swift uses ARC in a similar way as Objective-C does. ARC has been discussed extensively.

In short:

  1. There is no garbage collector.
  2. Objects live as long as (strong) references exist.
  3. Strong references can't be cyclic, otherwise you leak memory. Use weak references to break cycles.
Community
  • 1
  • 1
Nikolai Ruhe
  • 81,520
  • 17
  • 180
  • 200
  • So it's not perfect, and as developer I need to be aware of it. Right? – Ilya Gazman Jun 03 '14 at 15:32
  • 1
    "Perfect" seems to be a very opinion specific label, so I won't answer on that. And, yes, there are cases where you have to be aware of memory management, as with every other language. – Nikolai Ruhe Jun 03 '14 at 15:34
  • The main risk seems to be, as in ObjC, retain cycles in closures (blocks). – Ben Gottlieb Jun 03 '14 at 15:42
  • What is the difference from garbage collector? – Gokhan Arik Jun 03 '14 at 15:49
  • @Ilya_Gazman Both garbage collection as well as ARC depend on the compiler *and* perform work at runtime. While the main advantage of the collector is that it finds cycles, reference counting gives you deterministic deallocation and a bit less runtime overhead. – Nikolai Ruhe Jun 03 '14 at 16:06
  • @NikolaiRuhe Not according [wiky](http://en.wikipedia.org/wiki/Automatic_Reference_Counting) it's not. – Ilya Gazman Jun 03 '14 at 16:13
  • 2
    @GokhanArik `garbage collection` typically implies a runtime process that follows accessibility from a set of root objects to determine what objects are no longer in use. It has the advantage that it is not (as) susceptible to reference loops and the disadvantage that it can be a large (generally indeterminate) runtime processor sink. ARC and other reference counting schemes do more work at compile time to get deterministic behavior at runtime, but are susceptible to reference loops. – David Berry Jun 03 '14 at 16:59
  • Thanks a lot, it makes more sense now – Gokhan Arik Jun 03 '14 at 17:16
  • @Ilya_Gazman Please be more specific about what you find contradictory. – Nikolai Ruhe Jun 03 '14 at 17:26
  • @NikolaiRuhe ARC is compile time technology it does not do anything in runtime. – Ilya Gazman Jun 03 '14 at 17:44
  • 1
    @Ilya_Gazman That's not really true: While the main concept of ARC is that the compiler automatically inserts retain and release calls, there has been added quite a bit of runtime functionality with ARC. There are a lot of new functions to perform the various retain/release/autorelease tasks, as well as new autorelease pools, among other stuff. If ARC was a pure compile time technology, it would be backwards compatible to Mac OS X 10.0 and iOS 1.0. – Nikolai Ruhe Jun 03 '14 at 18:13
  • @NikolaiRuhe can you update your answer with reference to that. Everyone who I bee speaking so far, claiming that ARC do not run at runtime. – Ilya Gazman Jun 03 '14 at 18:19
  • @Ilya_Gazman See for example the [ARC runtime documentation](http://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support). It starts by explicitly naming the two parts of ARC: "the interaction between the ARC runtime and the code generated by the ARC compiler" – Nikolai Ruhe Jun 03 '14 at 18:22
  • Nikolai,Can you please explain the meaning of "Strong references can't be cyclic, otherwise you leak memory. Use weak references to break cycles". Whar=t do you mean by cyclic? –  Oct 17 '14 at 07:19
  • 1
    @JeffWood [Here's a description](https://en.wikipedia.org/wiki/Reference_counting#reference_cycle) of reference cycles in reference counted systems. – Nikolai Ruhe Oct 17 '14 at 07:32
  • "There is no garbage collector". Reference counting is a form of garbage collector. – J D Mar 04 '15 at 15:53
  • @DavidBerry: "garbage collection typically implies a runtime process that follows accessibility from a set of root objects to determine what objects are no longer in use". You are describing tracing garbage collection. – J D Mar 04 '15 at 15:53
  • @NikolaiRuhe: "reference counting gives you deterministic deallocation and a bit less runtime overhead". Actually reference counting is non-deterministic is the presence of threads as decrements race to zero and reference counting as a huge run-time overhead (that's why .NET and the JVM no longer use reference counting: it is very slow). – J D Mar 04 '15 at 15:57
  • @JonHarrop On the Apple platforms (and other places I'm familiar with) the term 'garbage collection' refers to a process that does not use reference counting and is synonymous with "tracing GC". This question is tagged "iOS" and clearly addresses only Apple platforms. In this context your comments are misleading. – Nikolai Ruhe Mar 04 '15 at 17:23
0

I know that the biggest difference between GC and ARC is that GC

Note that ARC is a form of GC.

is run time process while ARC is operates in compile time.

Both tracing GC and ARC do things at both compile time and at run time. ARC injects code that increments and decrements reference counts and, when the count falls to zero, collects the object and decrements all of the references it was pointing to recursively (potentially causing an unbounded amount of work to be done at run time as an arbitrarily large object graph is collected).

So when working with ARC the developer need to take care of memory in some scenarios.

Yes. You must always be careful to avoid cycles because they will never be collected.

J D
  • 48,105
  • 13
  • 171
  • 274
-1

How ARC Works

Every time you create a new instance of a class, ARC allocates a chunk of memory to store information about that instance. This memory holds information about the type of the instance, together with the values of any stored properties associated with that instance.

Additionally, when an instance is no longer needed, ARC frees up the memory used by that instance so that the memory can be used for other purposes instead. This ensures that class instances do not take up space in memory when they are no longer needed.

However, if ARC were to deallocate an instance that was still in use, it would no longer be possible to access that instance’s properties, or call that instance’s methods. Indeed, if you tried to access the instance, your app would most likely crash.

To make sure that instances don’t disappear while they are still needed, ARC tracks how many properties, constants, and variables are currently referring to each class instance. ARC will not deallocate an instance as long as at least one active reference to that instance still exists.

To make this possible, whenever you assign a class instance to a property, constant, or variable, that property, constant, or variable makes a strong reference to the instance. The reference is called a “strong“ reference because it keeps a firm hold on that instance, and does not allow it to be deallocated for as long as that strong reference remains.

https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html

Mike
  • 9,765
  • 5
  • 34
  • 59
  • This is exactly the question. Does it mean that they use run time process or it's compile time? Also This link appears in my question. – Ilya Gazman Jun 03 '14 at 15:44