Re:Apple Silicon M1: Black Magic Fuckery
by lilyball on Tuesday November 24, 2020 @06:33PM
(#25204283)
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.
[ Parent
| on HN ]
Re:Apple Silicon M1: Black Magic Fuckery
by steveklabnik on Tuesday November 24, 2020 @06:43PM
(#25204351)
(Rc does not use atomics, Arc does and from a peek at the source it does indeed use Relaxed)
Re:Apple Silicon M1: Black Magic Fuckery
by wahern on Tuesday November 24, 2020 @09:20PM
(#25205304)
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...
The native Swift retain (swift_retain above) seems to be somewhere inside this mess: https://github.com/apple/swift/blob/main/stdlib/public/runti...
Re:Apple Silicon M1: Black Magic Fuckery
by lilyball on Wednesday November 25, 2020 @01:16AM
(#25206437)
What you’ve linked is CoreFoundation’s retain, Objective-C’s can be found in 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.