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
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
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
Rename the existing misleadingly-named "isClassType" to "isClassObject", and document that it refers to (swift or ObjC) class objects, the latter of which aren't always type metadata.
Swift SVN r22153
I introduced a function swift_keepAlive2() which has a different signature from
swift_keepAlive() until I can verify that the stdlib is using the new
infrastructure.
The difference in signature is that swift_keepAlive2 takes just a pointer while
swift_keepAlive also takes a metadata value that is not necessary for our
purposes anymore.
Swift SVN r21718
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
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
We were rounding the size up to the alignment when allocating a new object (swift_allocObject) but not when directly allocating memory for a non-object (swift_slowAlloc). The deallocation code wasn’t rounding the size up to the alignment at all. Overall, this meant that we would get the wrong index into the allocation cache when deallocating an object whose size got rounded in a way that affects the index.
Fixes <rdar://problem/17542859>, where println(5) would fail on the 32-bit iOS simulator when building the runtime without NDEBUG (so we get extra checking) and the standard library is built without optimization (which keeps a certain 33-byte allocation on the heap). The Interpreter/SDK/objc_cast.swift test triggers this when built under those conditions.
Swift SVN r19499
Revert "[stdlib] Use an enum for ArrayBuffer storage"
This reverts commit r18996.
This reverts commit r18954.
The optimizer is not ready yet to handle this change especially given
the time until Beta 3. After speaking with DaveA, we agreed to revert
this and take such large changes onto private branches until we are sure
that the optimizer is ready to handle them rather than risking
performance regressions due to hitting the "optimization cliff".
Swift SVN r19026
Also update ArrayBuffer to take advantage of it.
This change allows us to pass a word-sized enum with a native object
reference payload directly to the runtime, without switching on the enum
to unwrap the contents. Even though that unwrapping was semantically
equivalent to bit masking, it was causing fits in the optimizer.
Swift SVN r18996
not an alignment value.
Assert that various entrypoints get an alignment mask.
Get everything uniformly passing an assertion about
dealloating an object with the correct allocation
size; don't actually enable the assertion yet, though.
rdar://16989632
Swift SVN r18550
and alignment for the purposes of deallocation.
If a class contains a method named __getInstanceSizeAndAlignMask,
and it takes no arguments and returns a pair of words, call
that method directly in order to get the size and alignment
mask instead of trusting the class's formal size and alignment.
This is not a replacement for a proper language solution for
custom allocation, but it'll suffice to fix some immediate
problems with HeapBufferStorage.
If we decide we like this approach, we should really raise
the deallocating destructor up to SIL.
rdar://16979846
Swift SVN r18485
weak references at deallocation time.
Also, directly call swift_slowDealloc in swift_weakRelease
instead of incorrectly recursing back into
swift_deallocObject.
Also document the correctness of the fast-path check
we do in swift_deallocObject.
rdar://16967569
Swift SVN r18475
This bug was a result of code drift between the hand written assembly
and the generic code. Thankfully we disabled the hand written assembly a
while a go, which made this bug easier to find.
This fixes: <rdar://problem/16954674>
Swift SVN r18425
Apparently Builtin.fixLifetime isn't yet respected
(<rdar://problem/16464507>) and calls to that and swift_keepAlive were
getting scattered around randomly. Let's have a convenient library
function instead.
Swift SVN r17493
DaveZ says: In the future we're likely to store "associated objects,"
which will make inlining the introspection of the reference count
problematic.
Swift SVN r17481
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
Also fix a latent bug in the logic in the disabled code to scribble over memory durring dealloc.
<rdar://problem/15855042> QoI: abort on resurrection
Swift SVN r16827
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
