BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Swift Memory Ownership Manifesto

Swift Memory Ownership Manifesto

This item in japanese

Bookmarks

According to Chris Lattner, Swift creator and Swift team lead before moving to Tesla, defining a Rust/Cyclone-inspired memory ownership model is one of the main goals for Swift 4. Now that Swift 4 has entered its phase 2, the Swift team has published a manifesto detailing how Swift memory ownership could work.

Swift’s compiler does actually implement its own, opaque ownership model (ARC) to decide when ownership should be transferred. There are cases when this is obvious, and cases where the compiler can make the wrong assumptions, thus causing unnecessary copying. In a nutshell, Swift’s new memory ownership model will try to put under the developer’s control when memory is copied. The main objective of defining a memory ownership model for Swift is trying to overcome the drawbacks that the current copy-on-write reference counting approach has. Those are the overhead and occasionally unpredictable performance of reference counting, and the need to generally allocate memory on the heap due to the requirement of being able to copy at any time.

Such drawbacks, while not generally a problem for application programming, can be undesirable for system programming in those cases where specific performance guarantees are required. Additionally, the benefits of a more flexible memory management model can be significant even for application programming when trying to optimize specific bottlenecks. Based on this, Swift’s new memory ownership model will be opt-in, so only developers requiring that finer-graded control will incur the cost of its complexity, compared to ARC.

One change that will affect all Swift developers, though, is the “Law of exclusivity”, which will not be opt-in. This law will enforce that a variable cannot be accessed simultaneously in conflicting ways, such as when it would be passed as an inout argument to two different functions, or when method receives a callback that accesses the same variable that the method was called on. Both cases are currently allowed in Swift, and ruling them out will affect all developers. Moreover, since the Law of exclusivity has an impact on the language ABI, because it changes the guarantees made for parameters, it will be one of the first features to be adopted.

In addition to the “Law of exclusivity”, Swift will introduce new annotations and language features to allow the propagation of shared values and to express types that cannot be implicitly copied. Those three mechanisms – exclusivity, explicit control of shared values propagation, and non-copyable types – play together to make it possible for the compiler to optimize the code more aggressively, according the the Manifesto’s authors.

Succinctly, the high-level picture of the new Swift ownership model could be summarized as follows:

  • The compiler will flag all non-exclusive uses of inout, whether explicit or implicit, as explained above.
  • Developers will be able to declare whether a variable is owned or shared, to avoid reference counting and unnecessary copying/destroying when entering/leaving lexical scopes.
  • Developers will be able to declare moveonly (i.e., non-copyable) types, that the compiler will not copy and that cannot be used to create additional references. moveonly types will have move semantics and are considered an advanced-features, so by default all types will be copyable.

The Manifesto itself provides quite a long and detailed analysis of all aspects that the definition of such an ownership model entails for Swift, and its details are not necessarily final, yet. A shorter, though quite dense summary of its key points has been published by Swift developer Alexis Beingessner.

Rate this Article

Adoption
Style

BT