[swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.
dabrahams at apple.com
Mon Feb 6 16:16:21 CST 2017
on Mon Feb 06 2017, John McCall <rjmccall-AT-apple.com> wrote:
>> On Feb 4, 2017, at 6:45 PM, Dave Abrahams via swift-dev <swift-dev at swift.org> wrote:
>> on Fri Feb 03 2017, John McCall <swift-dev-AT-swift.org> wrote:
>>>> On Feb 3, 2017, at 7:12 PM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
>>>> Given that most open-coded resilient method lookup paths require an
>>>> extra load dependency to grab the method offset before loading the
>>>> method address itself, we might possibly consider indirecting the
>>>> vtables for each class, so that the top-level vtable contains
>>>> [address of root class vtable, address of first child class vtable,
>>>> etc.]. If a class hierarchy is fixed once exported (in other words,
>>>> you can't insert a superclass into an inheritance chain without an
>>>> ABI break), then the offset into each superclass's pointer in the
>>>> vtable would be statically known, and the offset into each
>>>> second-level vtable could be statically known via sorting by
>>>> availability. This somewhat matches how we lay out protocol witness
>>>> tables, where each parent protocol's witness table is indirectly
>>>> referenced instead of being inlined into the leaf witness
>>>> table. (OTOH, method offsets can be cached and reused to dispatch
>>>> the same method on different objects, whereas we would have to
>>>> perform the load chain once per object per method with this
>>> Great point.
>>> I'm still uncomfortable with the idea of assuming that we can't insert
>>> a superclass into an inheritance chain. This isn't an assumption
>>> that's otherwise necessary or even useful, unless we decide to start
>>> optimizing dynamic casts.
>> Does that mean we don't need to make such an assumption for protocols
>> either? That would be a big relief for me, if so.
> I think we can probably implement the ability to extract a
> super-protocol resiliently, yeah. You'd get some requirements in
> redundant positions, but that's not so bad.
More information about the swift-dev