[swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations
clattner at apple.com
Tue Oct 11 13:25:48 CDT 2016
On Oct 11, 2016, at 10:10 AM, Michael Gottesman <mgottesman at apple.com> wrote:
>> >If ARC Code Motion wishes to move the ARC semantics of ownership qualified load, store instructions, it must now consider read/write effects. On the other hand, it will be able to now not consider the side-effects of destructors when moving retain/release operations.
>> Can you elaborate on what you mean by this? Does this mean the ARC optimizer has additional freedom somehow to ignore side effects in deinits? What grants that ability?
> Sorry for not being clear.
> deinits in ARC are not sequenced with respect to memory operations in normal control flow, but if ARC performs any code motion, we must ensure that memory safety is respected. Such semantics are not new.
> The main change here is that previously there were situations where we would split up the load/retain in a load [copy] operation. Then if the right things occured, we could cause the object to be deallocated before we use the value or took full ownership of the value.
Ah, I see what you mean. Got it.
> In this case, we would be passing off to useD a deallocated instance of class D1 which would be undefined behavior.
> So as long as for these load [copy] operations, we move the load/retain fused together, we can guarantee that an object is produced instantaneously in a safe way without any worry.
> Was this helpful?
Yep, totally. The new approach is much more clear, thanks Michael!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev