We were missing -_tryRetain, -_isDeallocating, -allowsWeakReference and -retainWeakReference implementations on SwiftObject, so forming an ObjC weak reference to a pure Swift object always failed and produced a nil reference. Fixes rdar://problem/18637774.
This can be reapplied now that we properly call objc_destructInstance on deallocation.
Swift SVN r23070
Generated code on x86_64 for swift_retain and swift_release and
swift_allocObject are unchanged. arm64 is improved by using weaker
memory barriers, fixing rdar://17423624.
Swift SVN r22887
This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
We were missing -_tryRetain, -_isDeallocating, -allowsWeakReference and -retainWeakReference implementations on SwiftObject, so forming an ObjC weak reference to a pure Swift object always failed and produced a nil reference. Fixes rdar://problem/18637774.
Swift SVN r22710
Strings that get used to name SpriteKit nodes on Mavericks end up weakly referenced by NSMapTables using the legacy GC-compatible weak pointer personality, which for our bridged objects ended up falling into the default NSObject implementation of reference counting via the "_tryRetain" SPI, causing heap corruption. I tried really hard to isolate a test case and failed, but this fixes the Adventure crasher in <rdar://problem/17887502>.
Swift SVN r20966
The allocator's crimes include:
* It uses OS SPI that must not be used by non-OS apps.
* It does not play well with memory debugging tools like Instruments.
* It does not return memory to the OS in response to memory pressure.
* It is less tested than we would like because many configurations
inadvertently turn it off (such as running from Xcode).
* Its per-thread magazine implementation does not actually work.
* Its "try alloc" flag is incompletely implemented and never used.
* Its "zero fill" flag is unimplemented and inconsistently used.
Swift SVN r20757
Rather than go through reentrant and problematic contortions to make Swift
work with the existing Instruments hooks, they agreed to just patch some
globals that we provide to get their logic to be activated.
Swift SVN r17144
Now that we can read definitions directly from "C" headers, stop trying
to maintain a mirror of the HeapObject struct in Swift code in the
standard library.
Swift SVN r14982
Implicit conversions to and from an unsigned long long enum class give us the calling convention we want for swift_allocBox without totally destroying the API for C callers.
Swift SVN r14919
