> On Feb 3, 2017, at 8:47 PM, John McCall <rjmcc...@apple.com> wrote:
>
>> On Feb 3, 2017, at 7:12 PM, Joe Groff via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
