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

[Andrew Trick]

> On Feb 3, 2017, at 1:27 PM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Feb 3, 2017, at 4:18 PM, Andrew Trick <atrick at apple.com <mailto: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.

I was briefly over-thinking the problem… we could hoist the part that wasn’t dependent on the `isa`. That’s probably not important, and if it were, we could still hoist the cache lookup.

This option does seem to have the lowest immediate ABI cost (one symbol per class) with a tremendous amount of flexibility for optimizing both the dispatch code and the metadata representation.

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