Using the intrinsics is obnoxious because I needed them
to return Builtin.NativeObject?, but there's no reasonable
way to safely generate optional types from Builtins.cpp.
Ugh.
Dave and I also decided that there's no need for
swift_tryPin to allow a null object.
Swift SVN r23824
Pinning an object prevents it from being deallocated,
just like retaining it, but only one client can own the
pin at once. Sensible "sharing" of the pin can occur
if attempts are perfectly nested. It is efficient to
simultaneously query the pin state of an object in
conjunction with its strong reference count.
This combination of traits makes pinning suitable for
use in tracking whether a data structure backed by
an object is undergoing a non-structural modification:
- A structural change would require unique ownership
of the object, but two non-structural changes (to
different parts of the object) can occur at once
without harm. So a non-structural change can check
for either uniqueness or a pin and then, if necessary,
assert the pin for the duration of the change.
Meanwhile, this act of asserting the pin prevents
simultaneous structural changes.
- A very simple code-generation discipline leads to
changes being perfectly nested as long as they're
all performed by a single thread (or synchronously).
Asynchrony can introduce imperfect nesting, but it's
easy to write that off as a race condition and hence
undefined behavior.
See Accessors.rst for more on both of these points.
Swift SVN r23761
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
