This CL lands the Clang-side support for a new Objective-C runtime feature that adds support for dynamically-allocated metadata.
What follows is a basic description of this mechanism:
In Swift, the class metadata contains an Objective-C class object as a prefix, followed by a vtable, generic parameters, and field offsets. If the inheritance hierarchy of a class crosses a resilience boundary, we cannot statically emit the entire metadata. Instead, it is lazily built at runtime when first needed.
In order for such classes to be accessed from Clang, the Objective-C runtime will support a new mechanism whereby Swift can instead emit a "class stub" object. The class stub object is used by Clang in places where a class reference is normally emitted:
- Classrefs emitted when messaging the class
- Categories
A class stub contains an "isa pointer" which is a scalar value 1 followed by a function pointer which realizes the real class metadata. A reference to a class stub from a classref also has its least significant pointer set to 1.
The Objective-C runtime distinguishes a class stub from a real class using this fake "isa pointer". Instead of directly loading from a classref, Clang instead calls objc_loadClassref(); this function checks if the classref contains a class stub, and if so, it calls the function pointer and stores the result back into the classref to fast path future loads.
Note that Clang already supports a objc_runtime_visible attribute. The objc_class_stub attribute can be thought of as a generalization of objc_runtime_visible. Whereas objc_runtime_visible replaces the classref load with a runtime lookup of a class by string, the class stub mechanism is more efficient because the result of the lookup is cached. Also, objc_runtime_visible does not support categories to be defined on the class, whereas objc_class_stub does.
If this is code, should it be using a code type rather than a string type?