Move the following from IRGen to runtime:
- Copying generic parameters from superclass to subclass
- Copying field offsets from superclass to subclass
- Initializing the Objective-C runtime name of the subclass
This eliminates some duplication between the generic subclass and
concrete subclass of a generic class cases.
Also this should reduce generated code size and have no impact on
performance (the instantiation logic only runs once per substituted
type).
class B<T> : NSFoo {}
class A : B<Int> {}
IRGen computes the ivar layout starting from offset zero, since
the size of the 'NSFoo' is unknown and we rely on the Objective-C
runtime to slide the ivar offsets.
The instantiated metadata for B<Int> would contain a field offset
vector with the correct offsets, because of how
swift_initClassMetadata_UniversalStrategy() works.
However, A's metadata is emitted statically, and this includes a
copy of the field offset vector from the superclass. A's metadata
was initialized by swift_initializeSuperclass(), which did not
copy the field offset vector over from A<Int>. And since the
Objective-C runtime only slides the immediate ivars of a class,
the field offsets corresponding to A<Int>'s fields in B's type
metadata were never slid, resulting in problems when an instance
of B was passed to a function operating on an A<T> generically.
Fixes <rdar://problem/23200051>.
Decrease the size of nominal type descriptors and make them true-const by relative-addressing the other metadata they need to reference, which should all be included in the same image as the descriptor itself. Relative-referencing string constants exposes a bug in the Apple linker, which crashes when resolving relative relocations to coalesceable symbols (rdar://problem/22674524); work around this for now by revoking the `unnamed_addr`-ness of string constants that we take relative references to. (I haven't tested whether GNU ld or gold also have this problem on Linux; it may be possible to conditionalize the workaround to only apply to Darwin targets for now.)
Reuses the enum metadata layout and builder because most of the logic is
also required for Optional (generic arg and payload). We may want to
optimize this at some point (Optional doesn't have a Parent), but I
don't see much opportunity.
Note that with this approach there will be no change in metadata layout.
Changing the kind still breaks the ABI of course.
Also leaves the MirrorData summary string as "(Enum Value)". We should
consider changing it.
Set up a separate libSwiftStubs.a archive for C++ stub functionality that's needed by the standard library but not part of the core runtime interface. Seed it with the Stubs.cpp and LibcShims.cpp files, which consist only of stubs, though a few stubs are still strewn across the runtime code base.
We now have dedicated tags for Swift on Apple operating systems. They are called: VM_MEMORY_SWIFT_RUNTIME and VM_MEMORY_SWIFT_METADATA.
Let's make use of them. This would allow tools like Instruments provide a more detailed analysis and statistics.
For now, we only tag the metadata allocations, as this is the only place where we use mmap at the moment.
rdar://22376248
Swift SVN r32584
Thanks to this, we can get rid of these two dirty symbols:
19f0f24e0 __ZZN17MetadataAllocator5allocEmE12pagesizeMask 8
19f0f24e8 __ZGVZN17MetadataAllocator5allocEmE12pagesizeMask 8
This is part of the effort to put the stdlib into a shared cache.
rdar://22375554
Swift SVN r31388
Full type metadata isn't necessary to calculate the runtime layout of a dependent struct or enum; we only need the non-function data from the value witness table (size, alignment, extra inhabitant count, and POD/BT/etc. flags). This can be generated more efficiently than the type metadata for many types--if we know a specific instantiation is fixed-layout, we can regenerate the layout information, or if we know the type has the same layout as another well-known type, we can get the layout from a common value witness table. This breaks a deadlock in most (but not all) cases where a value type is recursive using classes or fixed-layout indirected structs like UnsafePointer. rdar://problem/19898165
This time, factor out the ObjC-dependent parts of the tests so they only run with ObjC interop.
Swift SVN r30266
Full type metadata isn't necessary to calculate the runtime layout of a dependent struct or enum; we only need the non-function data from the value witness table (size, alignment, extra inhabitant count, and POD/BT/etc. flags). This can be generated more efficiently than the type metadata for many types--if we know a specific instantiation is fixed-layout, we can regenerate the layout information, or if we know the type has the same layout as another well-known type, we can get the layout from a common value witness table. This breaks a deadlock in most (but not all) cases where a value type is recursive using classes or fixed-layout indirected structs like UnsafePointer. rdar://problem/19898165
Swift SVN r30243
We incorrectly tested the uninitialized "next" pointer against MAP_FAILED, instead of the real result of mmap. Fixes rdar://problem/21659505.
Swift SVN r30030
Provide new swift_{alloc,dealloc,project}Box2 entry points that allocate, project, and deallocate typed boxes using runtime-instantiated metadata. Give these a new metadata kind, so that external tools recognize the difference and can interpret the metadata appropriately.
Swift SVN r29714
Now that we have lazy metadata accessors for classes and vtable thunking, we don't have any reason to prevent concrete subclasses of generic base classes. Wire up IRGen to lazily instantiate the superclass for concrete derived classes when their metadata is accessed, using a runtime function that installs all the necessary pointers and metadata and registers the fully-initialized class with the ObjC runtime.
Swift SVN r28520
Configure the runtime to build with -Wglobal-constructors, and Lazy-fy almost everything that gets flagged. (I gave "swift_isaMask" a pass since that's almost definitely hot enough to warrant a static initialization.) Make some improvements to the Lazy wrapper, using aligned_storage to ensure that it's trivially constructed and destructed.
Swift SVN r28199
This has a couple benefits:
- Since metadata allocations are already guarded by a lock, the allocator doesn't require synchronization, and can be much much simpler and a little faster than malloc.
- By bypassing malloc, we also avoid tools like 'heap' prying into our metadata cache and misrepresenting cache entries keyed on classes as live objects, fixing rdar://problem/20562886.
In my unscientific local tests, this appeared to give a small across-the-board improvement to Onone performance in the perf test suite, though not far enough from noise for me to declare that definitively. Fixing the bug is the bigger point here.
Swift SVN r27856
We have enough flag bits on function types now to warrant stashing an extra word in the metadata key alongside the arguments and results, so add one, and pack the number of arguments, function convention, and 'throws' bit in there. This lets us merge the separate metadata caches for thick/thin/block/C functions into one, saving a bit of runtime memory, and simplifying a bunch of repetitive code in the runtime and IRGen.
This also fixes a subtle bug we had where the runtime getFunctionTypeMetadata function expected the result argument to be passed in the arguments array, but IRGen was passing it as a separate argument, which would have caused function type metadata to fail to be uniqued by result type.
Swift SVN r27651
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Add a 'mayTakeValue' function, which returns true if we're allowed to take the value from an existential container (assuming we own the existential container value). This is true for class and opaque existential containers, but not for boxed existentials, where multiple owners may share references to the boxed value. Also add a 'deinitExistentialContainer' function to do any cleanup that must happen after the value has been consumed out of an existential container. Fix up an off-by-one indirection level in the SwiftError implementations of the existing existential container methods.
Swift SVN r26561
Teach ExistentialTypeMetadata how to project out the value pointer, type metadata, and protocol witness table from ErrorType containers. NFC yet; the dynamic casting and reflection machinery needs further work to correctly handle ErrorType boxes.
Swift SVN r26509
If an existential type for a special protocol (not a composition) is instantiated, carry the special protocol identifier from that protocol to the existential, allowing us to easily recognize existentials with unique runtime characteristics.
Swift SVN r26436
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
