> On Feb 6, 2017, at 1:23 PM, Joe Groff <jgr...@apple.com> wrote: >> On Feb 3, 2017, at 8:47 PM, John McCall <rjmcc...@apple.com >> <mailto: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: > > > <FullSizeRender.jpeg> > 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.
Oh, that's a cute idea. John.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
