[cfe-dev] [Proposal]: Devirtualizing local methods (messages) in final class in Objective-C

David Chisnall via cfe-dev cfe-dev at lists.llvm.org
Wed Sep 12 00:49:57 PDT 2018


On 12 Sep 2018, at 06:24, John McCall via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> But I do think it's an interesting feature that would solve a significant problem for Objective-C programmers.  Currently, Objective-C programmers who need inlining for performance have to rewrite their methods as static functions, which requires them to rewrite the method calls as well.  Being able to easily turn those message sends into direct function calls would be great.

I don’t think I agree here.  One of the core design principles of Objective-C (somewhat violated by the property notation) is that new semantics must introduce new syntax. Currently if you see foo(x), then you know without looking at the definition of foo that it’s a direct C-style function call.  If you see [x foo] then you know that it’s late-bound dynamic dispatch that can be overridden with subclassing or reflection, can be proxies, and so on.

That said, I have two comments on the proposal:

1. The GNUstep runtime has a mechanism that allows safe inlining and inline caching, with a cheap check that the inlined version is still valid. I prototyped an LLVM optimisation that did this automatically about 10 years ago, but given the lack of open source Objective-C codebases where message dispatch is actually the bottleneck, I didn’t work on it much.  If Apple wants this feature, then it’s not tremendously difficult to add to the runtime and there’s a good 40 years of research into efficient dispatch mechanisms for Smalltalk-family languages that can be used to create a design.  I picked one point in a very large trade-off space, which may or may not be the correct one.

2. A feature like this would probably make more sense as an attribute on the caller, rather than the callee.  For example, something like [+x foo] or [@direct(x) foo]. That would allow callers to explicitly declare that they don’t mind being broken in the presence of reflection, without requiring the same breakage at every call site.

David





More information about the cfe-dev mailing list