of associated types in protocol witness tables.
We use the global access functions when the result isn't
dependent, and a simple accessor when the result can be cheaply
recovered from the conforming metadata. Otherwise, we add a
cache slot to a private section of the witness table, forcing
an instantiation per conformance. Like generic type metadata,
concrete instantiations of generic conformances are memoized.
There's a fair amount of code in this patch that can't be
dynamically tested at the moment because of the widespread
reliance on recursive expansion of archetypes / dependent
types. That's something we're now theoretically in a position
to change, and as we do so, we'll test more of this code.
This reverts commit 6528ec2887, i.e.
it reapplies b1e3120a28, with a fix
to unbreak release builds.
We're not currently doing it, but we will soon be able to use
swift_initializeSuperclass() for class layouts which are not
dependent on generic parameters. In this case, we still need
to set the Objective-C class name.
On the other hand, if we're doing resilient layout for a
non-generic class, we don't need to set the Objective-C class
name.
NFC since this isn't hooked up completely yet.
This reverts commit b1e3120a28.
Reverting because this patch uses WitnessTableBuilder::PI in NDEBUG code.
That field only exists when NDEBUG is not defined, but now NextCacheIndex, a
field that exists regardless, is being updated based on information from PI.
This problem means that Release builds do not work.
of associated types in protocol witness tables.
We use the global access functions when the result isn't
dependent, and a simple accessor when the result can be cheaply
recovered from the conforming metadata. Otherwise, we add a
cache slot to a private section of the witness table, forcing
an instantiation per conformance. Like generic type metadata,
concrete instantiations of generic conformances are memoized.
There's a fair amount of code in this patch that can't be
dynamically tested at the moment because of the widespread
reliance on recursive expansion of archetypes / dependent
types. That's something we're now theoretically in a position
to change, and as we do so, we'll test more of this code.
Now, such classes will emit a metadata pattern and use the
generic metadata instantiation logic.
This was all wired up to handle the case of no generic
parameters previously, to support resilient struct layout
in the runtime.
The swift_initializeSuperclass() entry point still exists,
providing a fast path for when there's no field layout to
do, which is currently always true if we have a concrete
class.
This entry point no longer needs the global lock, since
now we get a per-class lock from the metadata cache.
Also, previously we would call the superclass accessor
function on every access of class metadata for a concrete
subclass of a generic class. Now that we re-use the
existing metadata cache logic, this extra call only occurs
during initialization.
Both swift_initializeSuperclass() and
swift_initClassMetadata_UniversalStrategy() used to take
the superclass as a parameter, but this isn't really
necessary, since it was loaded out of the class metadata
immediately prior to the call by the caller. Removing
this parameter makes the ABI a little simpler.
Once class layout supports resilient types, we will also
use swift_initClassMetadata_UniversalStrategy() to lay
out classes with resilient types as fields.
Singleton metadata caches will still allocate a copy of
the template, which is a slight performance regression
from the previous implementation of concrete subclasses
of generic classes. This will be optimized soon.
Right now, the template can always be modified in place;
in the future, it will be possible to modify in place as
long as the superclass is fixed-layout; a resilient superclass
might add or remove fields, thus we cannot leave room for
it in the metadata of the subclass, and will need to grow
the metadata and slide field offsets at runtime using a
new entry point.
Also, the representation of the cache itself could be
optimized to handle the singleton case, since all we
really need here is a lock without any kind of mapping
table.
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
