ObjC unowned references are backed by an ObjC weak reference which will eagerly deallocate the object when it's strongly released, so in an unknown-refcount situation, we can't safely dereference the object pointer to determine its Swiftness. We can, however, look at the side table of weak references; if there's an entry for this object, then it's reliably an ObjC object (or it's some other object that got allocated in the reclaimed space for the dead object, but that's a race we fundamentally can't win with this broken design). Fixes rdar://problem/18091547 (modulo the aforementioned reallocation race).
Swift SVN r24825
Teach IRGen and the runtime about the extra inhabitants
of function pointers, and take advantage of that in
thin and thick function types.
Also add runtime entrypoints for thin function type
metadata.
Swift SVN r24346
Fixes a crash when some programs were run in JIT mode; they instantiated a JITed class before the ObjC subclass was realized. Send a message to super to realize the class before we try to readClassPair it. Fixes rdar://problem/19170232.
Swift SVN r23825
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
Previously we weren't accounting for the fact that
heap_object_abi::SwiftSpareBitsMask includes all the tagged pointer
demarcation bits in heap_object_abi::ObjCReservedBitsMask.
Swift SVN r23459
Naturally, the fast path for things like Array<Int> has to be that no
masking is required to get at the buffer. Therefore, the state with no
spare bits set needs to be reserved for native objects. After the
change, an ObjC non-tagged pointer is stored with all spare bits set, and
native objects are stored with 0..<N bits set, where N is the number of
spare bits. ObjC tagged pointers are still stored verbatim.
Swift SVN r23430
We used to reserve a specific spare bit to say "this is a native
object." Now, we're going to say, "if *any* spare bit is set, this is a
native object." At the cost of having no spare bits to work with in the
non-native case, this allows us to store a number in 1..<4 (actually
0..<4, at some cost in speed for the 0 case) along with any native
object on all platforms.
This half bit advantage is important on 32-bit platforms, we have only
spare 2 bits to work with.
Given that on the 64-bit platforms there are *no* spare bits in the case
where the object is a non-native tagged pointer, we have no guarantee of
being able to store extra information along with an arbitrary non-native
object. Giving up the ability to store bits for *all* non-native
objects (even non-tagged ones) is therefore not much of a sacrifice.
Fixes <rdar://problem/18920415> More useful spare bits in Builtin.BridgeObject
Swift SVN r23345
Renames swift_class_getInstanceSize to
swift_class_getInstancePositiveExtentSize to reflect that it is
the size of the object after the instance address point.
Swift SVN r23333
Just injecting a new protocol descriptor into an already-running ObjC runtime isn't a good idea, since the runtime might have already canonized the protocol somewhere else, and it won't recognize that classes conform to protocols it doesn't know about.
Swift SVN r23313
Clang overzealously infects SwiftObject with the HasCXXStructors bit because it contained a struct (with trivial constructor). Manually explode the struct to avoid this.
Swift SVN r23259
These always fail, and it doesn't make sense to inline this check into the cast site, so provide additional runtime functions for metatype-to-objc-existential casts.
Swift SVN r23237
stdint.h and stddef.h are shipped with CLang, but they not included in
Clang's module.map, which causes Clang to import libc versions instead
(and Clang's stdint.h is dispatching to libc). This was causing
hard-to-debug transient failures during incremental rebuilds, like this:
error: module file was created by an older version of the compiler: .../Darwin.swiftmodule
Swift SVN r23230
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
It was doing an unsafeBitCast and possibly not managing lifetimes;
replace it with more-typesafe and memory-safe calls where possible.
Swift SVN r22779
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
In ObjC, RootClass's metaclass isa RootClass, which is bad for SwiftObject, because its applying instance retain/release operations ends up clobbering internal state of the class. Add class method versions of 'retain' and 'release' that are no-ops, like +[NSObject retain/release] are. Fixes rdar://problem/18625294.
Swift SVN r22703
A revamped version of HeapBuffer that doesn't allow null buffer
references. Something like this is needed for killing the null array
state.
Swift SVN r22683
Make unique reference checking available to users, making ManagedBuffer
a complete facility for building COW value types. Also rationalize the
way we name and organize the runtime primitives we ultimately call.
Swift SVN r22594
Since ObjC functions take their arguments at +0, we don't need to erase
"object-ness" in order to avoid disturbing reference counts. This
interacts much better with lifetime optimizations, since the caller must
ensure the argument isn't released until these functions return.
Swift SVN r22580
instances of Swift subclasses of ObjC classes.
We were already doing this in the runtime. This patch
unhides the runtime's mask word (swift_isaMask) and makes
IR-gen take advantage of it when it can.
Swift SVN r21592
As part of the evolution toward a one-word array layout, create a type
that can be used to efficiently store Cocoa or Native class instances
and discriminate between them.
Swift SVN r21469
