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

[John McCall]

> On Feb 3, 2017, at 4:18 PM, Andrew Trick <atrick at apple.com> wrote:
>> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>>>> #3b. (lazy resolution) Offset tables can be completely localized.
>>>> 
>>>> method_index = immediate
>>>> { // common per-class method lookup
>>>>  isa = load[obj]
>>>>  offset = load[@local_class_method_table + method_index]
>>>>  if (!isInitializedOffset(offset)) {
>>>>    offset = @resolveMethodOffset(@class_id, method_index)
>>>>    store [@local_class_method_table + method_index]
>>>>  }
>>>>  if (isVtableOffset(offset))
>>>>    method_entry = load[isa + offset]
>>>>  else
>>>>    method_entry = @resolveMethodAddress(isa, @class_id, method_index)
>>>> }
>>>> call method_entry
>>> 
>>> The size of @local_class_method_table is not statically knowable.
>>> Fortunately, it doesn't matter, because this mechanism does not actually
>>> care about the table being contiguous; the lookup function could be
>>> passed a per-method cache variable.  This would also allow the lookup
>>> function to be shared between classes.
> 
> Hmm... I thought the local method offset table size could be statically knowable because it will only be accesd for methods that were publicly available at build time, based on the sorted method index.

Sure, I mean, you can pick a table size that's sufficient for all the offsets that will be passed.  That would save a few instructions at call sites, at the cost of requiring the resolvers to be per-class.

> We could simplify the method resolution API with a single exported symbol per-class (maybe that's what you're getting at):
> 
> method_entry = resolveMethodAddress_ForAClass(isa, method_index, &vtable_offset)

Right, this is what I was thinking.

> The problem with that is the client-side code can’t hoist and combine the method offset lookup anymore.

Why not?  vtable_offset is basically an opaque cache here.  Sure, technically the call isn't readnone anymore, but it's an innocuous violation like adding memoization to sin().

Or is there some finer-grained hoisting you're imagining than the entire call?

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170203/ef13704f/attachment.html>