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@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@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. >> >> 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.
So awesome. -- -Dave _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
