Commit Graph

14 Commits

Author SHA1 Message Date
Arnold Schwaighofer
d143e2d003 RefCount: Add an assert and some documentation
Incorporate John's feedback.

Swift SVN r24560
2015-01-20 20:40:08 +00:00
Arnold Schwaighofer
80a46cdae2 RefCount: Use rotate right in isUniquelyReferencedOrPinned
This generates more efficient code.

Swift SVN r24555
2015-01-20 17:00:12 +00:00
John McCall
524a0afee0 Strengthen and clarify the assertions in
swift_release and swift_unpin.

Swift SVN r24422
2015-01-14 19:14:26 +00:00
John McCall
3f46b30ca4 Add runtime functions to "pin" a native Swift object.
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
2014-12-06 09:46:01 +00:00
Graham Batty
0aaf9af5c9 Use a type_traits shim for is_trivially_constructible.
Swift SVN r23383
2014-11-17 21:23:20 +00:00
Graham Batty
243fb6de51 Don't do is_trivial_constrictible on libstdc++.
This is currently unimplemented as of this macro being 20141011,
when it is implemented in libstdc++ the check should be changed
to a < the version that implemented it.

Swift SVN r23368
2014-11-17 17:15:11 +00:00
Andrew Trick
96688dea2f Silince unused variable warnings.
Swift SVN r23341
2014-11-15 00:37:34 +00:00
Joe Groff
b9bd3a2fea Ensure HeapObject and RefCount objects are trivially constructible and destructible.
We don't want them to trigger .cxx_*struct behavior in our ObjC base classes after Clang is fixed.

Swift SVN r23332
2014-11-14 21:54:48 +00:00
Dmitri Hrybenko
af9515d754 Break a circular dependency between SwiftShims and the Darwin module
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
2014-11-11 02:26:06 +00:00
Dmitri Hrybenko
90624fd7a2 Use defined() instead of using a possibly not defined macra
Swift SVN r23229
2014-11-11 02:26:05 +00:00
Dmitri Hrybenko
caf00310fa Remove trailing whitespace
Swift SVN r23228
2014-11-11 02:25:54 +00:00
Greg Parker
c6a88262cf [stdlib] Scrap bit-rotted FastEntryPoints.s. Rewrite refcounts using __atomic.
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
2014-10-23 08:22:48 +00:00
Dave Zarzycki
d8e39d106a Runtime: finish SwiftObject
<rdar://problem/12640667> Implement SwiftObject root class

Swift SVN r15706
2014-03-31 23:10:39 +00:00
Dave Abrahams
6eee8e3205 Move HeapObject into the stdlib shim module
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
2014-03-12 23:48:31 +00:00