4 ms·

I sure hope so. In macOS 10.15, the fast path for a retain on a (non-tagged-pointer) Obj-C object does a C11 relaxed atomic load followed by a C11 relaxed compa

I sure hope so. In macOS 10.15, the fast path for a retain on a (non-tagged-pointer) Obj-C object does a C11 relaxed atomic load followed by a C11 relaxed compare-and-exchange. This seems pretty standard for retain-release and I'd expect Rust's Rc<> to be doing something similar. It's possible Apple added some other black magic to the runtime in 10.16 (and they haven't released the 10.16 objc sources yet) but it's hard to imagine what they'd do that makes more sense than just optimizing for relaxed atomic operations.

steveklabnik 6y ago
(Rc does not use atomics, Arc does and from a peek at the source it does indeed use Relaxed)
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 ago
  What 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.
saagarjha 6y ago
I’d think the bigger win would have to be in the release part of the code, which actually cares about contention.

steveklabnik 6y ago

(Rc does not use atomics, Arc does and from a peek at the source it does indeed use Relaxed)

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 ago
What 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.

saagarjha 6y ago

I’d think the bigger win would have to be in the release part of the code, which actually cares about contention.