[swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

[Joe Groff]

> On Feb 3, 2017, at 8:47 PM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Feb 3, 2017, at 7:12 PM, Joe Groff via swift-dev <swift-dev at swift.org <mailto: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 approach.)
> 
> 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.

Fair point. Jordan also noted that inserting superclasses is something that has happened in practice with Apple's frameworks in the past.

> 
> Assuming it's valid, some additional trade-offs that come to mind:
>  - It adds a load dependency to non-resilient dispatch, which is probably what we should be optimizing for.  We have an easy answer when someone asks why their resilient dispatch is a bit slower. We don't have easy ways to make non-resilient dispatch faster.

If we have control over how the class object grows in both directions, we could potentially mitigate the fragile dispatch case, by having the subtable pointers grow in one direction, pointing into sub-vtables that are stored inline in the other direction, something like this:



so that code with full knowledge of the class hierarchy can directly address methods at static offsets, and only resilient clients need to use the subtable pointers.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170206/1fc3413e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FullSizeRender.jpeg
Type: image/jpeg
Size: 34612 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170206/1fc3413e/attachment.jpeg>