3 ms·
I didn't understand why the implementation wouldn't just do an atomic increment, but I guess Obj-C semantics provide too much magic to permit such a simple appr
by wahern 6y ago
I didn't understand why the implementation wouldn't just do an atomic increment, but I guess Obj-C semantics provide too much magic to permit such a simple approach. The actual code, in addition to [presumably] not being inlined, does not seem easy to optimize at the hardware level: https://github.com/apple/swift-corelibs-foundation/blob/main/CoreFoundation/Base.subproj/CFRuntime.c#L1365 https://github.com/apple/swift-corelibs-foundation/blob/main...
The native Swift retain (swift_retain above) seems to be somewhere inside this mess: https://github.com/apple/swift/blob/main/stdlib/public/runtime/HeapObject.cpp https://github.com/apple/swift/blob/main/stdlib/public/runti...
- lilyball 6y agoWhat you’ve linked is CoreFoundation’s retain, Objective-C’s can be found in https://opensource.apple.com/source/objc4/objc4-787.1/runtime/objc-object.h.auto.html https://opensource.apple.com/source/objc4/objc4-787.1/runtim... (look for objc_object::rootRetain). The short answer for why it can’t just be an increment is because the reference count is stored in a subset of the bits of the isa pointer, and when the reference count grows too large it has to overflow into a separate sidetable. So it does separate load and CAS operations in order to implement this overflow behavior.