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

Andrew Trick atrick at apple.com
Fri Feb 3 15:18:08 CST 2017


> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev <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.

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)

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

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


More information about the swift-dev mailing list