> On Dec 1, 2016, at 4:55 PM, Jiho Choi <jray...@gmail.com> wrote:
> Thanks for the explanation.
> One last question is why non-atomic ARC operations still use atomic load and 
> store.  Wouldn't regular memory operations be enough?

They use atomic operations with __ATOMIC_RELAXED, which basically means that 
they should load/store the counts as one single entity (i.e. a single 64bit 
word) and not as multiple parts. Aside from that, it does not involve any 
further overheads known from CAS/fetch-and-add type of atomic operations. 

You can actually see the assembly for this functions to see which machine 
instructions are generated.

> On Thu, Dec 1, 2016 at 11:46 AM Roman Levenstein <rlevenst...@apple.com 
> <mailto:rlevenst...@apple.com>> wrote:
>> On Nov 30, 2016, at 9:40 PM, Jiho Choi <jray...@gmail.com 
>> <mailto:jray...@gmail.com>> wrote:
>> Thanks for providing the pointer.
>> Do you have any preliminary result or goal (e.g. the replacement ratio) of 
>> the optimization? 
>> Is it going to replace all ARC operations with non-atomic ones for 
>> single-threaded applications?
> In the ideal world, it would be nice to replace all ARC operations with 
> non-atomic ones for single-threaded applications. 
> But in reality, it is way more difficult as it may seem at the first glance. 
> If this needs to happen without any hints from the developer, just by means 
> of a static analysis of a program, then it is rather difficult. The main 
> problem is that the compiler needs to reason whether a given reference may 
> escape to another thread. For references created inside a function, we have 
> rather good chances to figure out if a reference escapes the thread. But if 
> the origin (i.e. how it was created or if it has escaped before) of a given 
> reference is unknown, which is a typical case with function parameters or 
> references inside class instances, then the compiler has to assume that any 
> such reference has escaped its original thread and thus it needs to use 
> atomic ARC-operations. Some sort of a global, whole-module/whole-program 
> analysis may help here somewhat. But even if we would introduce such kind of 
> analysis, it is likely to remain a problem for dynamic libraries and 
> frameworks, because they don’t know and cannot reason which parameters 
> required by their exposed APIs escaped in the user-code.
> Alternatively , a developer could provide a hint and assure that compiler 
> that the app is single-threaded. One simple possibility could be to have a 
> special -single-threaded compiler option, which would basically claim that 
> the app being developed is single threaded and thus there is no need for 
> performing the atomic ARC operations. In this case, all ARC operations would 
> be marked non-atomic by default in the code emitted from the user-code. The 
> problem with this option could be that if a user app starts multiple threads 
> directly or indirectly (e.g. it calls a library API, which starts a new 
> thread), even though the option claimed the app would not do it,  and some 
> references will be shared between threads, then the execution of such an app 
> may become unpredictable and end up with hard to find crashes. Mixing object 
> files and libraries where a subset is compiled with this option and another 
> part without is another receipt for a disaster. So, one would need to be 
> extremely cautious when using this option. 
> There could be also something in between, where one would use special 
> attributes indicating something related to thread-safety of a given 
> reference/type/function/etc. These hints could help a compiler to reason 
> about references and check if they may escape to a different thread.
> -Roman
>> On Wed, Nov 30, 2016 at 8:50 PM Roman Levenstein <rlevenst...@apple.com 
>> <mailto:rlevenst...@apple.com>> wrote:
>>> On Nov 30, 2016, at 6:25 PM, Jiho Choi via swift-dev <swift-dev@swift.org 
>>> <mailto:swift-dev@swift.org>> wrote:
>>> Thanks for clarifications.  I have a couple of follow-up questions.
>>> 1. Could you please provide more information (e.g. source code location) 
>>> about the optimization applying non-atomic reference counting?  What's the 
>>> scope of the optimization?  Is it method-based?
>> The optimization itself is not merged yet. But all the required machinery, 
>> e.g. non-atomic versions of the ARC operations, special non-atomic flag on 
>> SIL instructions, etc is in place already.
>> As for the prototype implementation, you can find it here, on my local 
>> branch:
>> https://github.com/swiftix/swift/blob/30409865ff49a4268363cd359f82f29c9a90cce8/lib/SILOptimizer/Transforms/NonAtomicRC.cpp
>> <https://github.com/swiftix/swift/blob/30409865ff49a4268363cd359f82f29c9a90cce8/lib/SILOptimizer/Transforms/NonAtomicRC.cpp>
>>> 2. Looking at the source code, I assume Swift implements immediate 
>>> reference counting (i.e. immediate reclamation of dead objects)  without 
>>> requiring explicit garbage collection phase for techniques, such as 
>>> deferred reference counting or coalescing multiple updates.  Is it right?  
>>> If so, is there any plan to implement such techniques?
>> Yes. It is a correct understanding. 
>> Different extensions like deferred reference counting were discussed, but 
>> there are no short-term plans to implement it anytime soon.
>> -Roman
>>> On Wed, Nov 30, 2016 at 11:41 AM John McCall <rjmcc...@apple.com 
>>> <mailto:rjmcc...@apple.com>> wrote:
>>>> On Nov 30, 2016, at 8:33 AM, Jiho Choi via swift-dev <swift-dev@swift.org 
>>>> <mailto:swift-dev@swift.org>> wrote:
>>>> Hi,
>>>> I am new to Swift, and I have several questions about how ARC works in 
>>>> Swift.
>>>> 1. I read from one of the previous discussions in the swift-evolution list 
>>>> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html
>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html>)
>>>>  that ARC operations are currently not atomic as Swift has no memory model 
>>>> and concurrency model.  Does it mean that the compiler generates 
>>>> non-atomic instructions for updating reference counts (e.g. using 
>>>> incrementNonAtomic() instead of increment() in RefCount.h)?
>>> No.  We have the ability to do non-atomic reference counting as an 
>>> optimization, but we only trigger it when we can prove that an object 
>>> hasn't escaped yet.  Therefore, at the user level, retain counts are atomic.
>>> Swift ARC is non-atomic in the sense that a read/write or write/write race 
>>> on an individual property/variable/whatever has undefined behavior and can 
>>> lead to crashes or leaks.  This differs from Objective-C ARC only in that a 
>>> (synthesized) atomic strong or weak property in Objective-C does promise 
>>> correctness even in the face of race conditions.  But this guarantee is not 
>>> worth much in practice because a failure to adequately synchronize accesses 
>>> to a class's instance variables is likely to have all sorts of other 
>>> unpleasant effects, and it is quite expensive, so we decided not to make it 
>>> in Swift.
>>>> 2. If not, when does it use non-atomic ARC operations? Is there an 
>>>> optimization pass to recognize local objects?
>>>> 3. Without the concurrency model in the language, if not using GCD (e.g. 
>>>> all Swift benchmark applications), I assume Swift applications are 
>>>> single-threaded.  Then, I think we can safely use non-atomic ARC 
>>>> operations.  Am I right?
>>> When we say that we don't have a concurrency model, we mean that (1) we 
>>> aren't providing a more complete language solution than the options 
>>> available to C programmers and (2) like C pre-C11/C++11, we have not yet 
>>> formalized a memory model for concurrency that provides formal guarantees 
>>> about what accesses are guaranteed to not conflict if they do race.  (For 
>>> example, we are unlikely to guarantee that accesses to different properties 
>>> of a struct can occur in parallel, but we may choose to make that guarantee 
>>> for different properties of a class.)
>>>> 4. Lastly, is there a way to measure the overhead of ARC (e.g. a compiler 
>>>> flag to disable ARC)?
>>> No, because ARC is generally necessary for correctness.
>>> John.
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev 
>>> <https://lists.swift.org/mailman/listinfo/swift-dev>

swift-dev mailing list

Reply via email to