gnustep/libobjc2

objc_direct methods

Closed this issue · 4 comments

Not quite. They also need to ensure that the +initialize method is invoked. There's a comment in the Mac version that describes some of this:

  // Generate:
  //
  // /* for class methods only to force class lazy initialization */
  // self = [self self];
  //
  // /* unless the receiver is never NULL */
  // if (self == nil) {
  //     return (ReturnType){ };
  // }
  //
  // _cmd = @selector(...)

I think this is actually wrong, because if you do objc_allocateInstance and then send it a message, it won't call +initialize and they've broken the language semantics.

I don't really like requiring a message send here, because it largely defeats the point of direct messages for efficiency. I'm tempted to add an __objc_initialize function to guarantee that +initialize has been called. I'm also tempted to make the caller responsible for calling it - if a static method is called from within another method on the same class (or a subclass) it can be elided, and a little bit of analysis should allow it to be elided elsewhere as well.

Looks like they know about this problem.
several entry points for direct methods
unnecessary class initialization in direct methods
Also in the recent Apple's objc runtime there are new runtime functions to bypass objc_msgSend for rarely overridden methods
such as self, new, class, isKindOfClass and respondsToSelector the functions are prefixed with objc_opt_* NSObject.mm

It looks as if the code for the objc_opt_ stuff is not in the public LLVM, only in Apple's fork.