Sending messages is inefficient because of selector lookup

[jrmuizel]

It would be better if selectors were resolved at compile time instead of using sel_registerName

[SSheldon]

I've been trying to mimic how clang does codegen for selectors. If you, say, call the hash method on an object it generates:

	.section	__TEXT,__objc_methname,cstring_literals
L_OBJC_METH_VAR_NAME_:                  ## @OBJC_METH_VAR_NAME_
	.asciz	"hash"

	.section	__DATA,__objc_selrefs,literal_pointers,no_dead_strip
	.align	3                       ## @OBJC_SELECTOR_REFERENCES_
L_OBJC_SELECTOR_REFERENCES_:
	.quad	L_OBJC_METH_VAR_NAME_

And then the selector passed to objc_msgSend is just loaded from L_OBJC_SELECTOR_REFERENCES_[0].

If I naively try to mimic this, with some code like:

const char *const MY_SELECTOR = "hash";

SEL selector = MY_SELECTOR;
NSUInteger hash = objc_msgSend(object, selector);

It does not go well, terminating with an unrecognized selector after printing:

NSForwarding: warning: selector (0x1008e0f8c) for message 'hash' does not match selector known to Objective C runtime (0x7fff9b927f35)-- abort`

With the naive mimicry, the generated code looks like:

	.section	__TEXT,__cstring,cstring_literals
L_.str:                                 ## @.str
	.asciz	"hash"

	.section	__DATA,__const
	.globl	_MY_SELECTOR            ## @MY_SELECTOR
	.align	3
_MY_SELECTOR:
	.quad	L_.str

The primary difference seems to be in the sections, particularly where MY_SELECTOR isn't in the __objc_selrefs section. Searching the objc runtime source code confirms that is important; in objc-file.mm there's the _getObjc2SelectorRefs function which looks through the __objc_selrefs section. I'm assuming that at initialization the runtime looks at all the selectors in this section and registers them.

So, some questions from here that I need to resolve:

• is there a way in rust to change what sections a constant is in?
• what happens if the same selector is used multiple places, is there a concern of it ending up in the __objc_selrefs section multiple times? Or will the linker de-duplicate them and I don't have to worry about it?

[jrmuizel]

I'll respond more in a bit but I got this sort of working:

    struct Foo(*const [u8; 9]);
    unsafe impl Send for Foo {}
    unsafe impl Sync for Foo {}

    {
        #[link_section="__TEXT,__objc_methname,cstring_literals"]
        static BAM : [u8; 9] = *b"Rustling\0";
        #[link_section="__DATA,__objc_selrefs,literal_pointers,no_dead_strip"]
        static LAMP: Foo = Foo(&BAM);
    }

Unfortunately, there doesn't seem to be a great way to generate the literal 9 constant.

I'm going to try to prototype a solution with a coworker in the new year.

[SSheldon]

Ooh interesting, good find with #[link_section]. I think it might not matter whether the strings are inside the __objc_methname section, I can't find any reference to it being read in the runtime. Putting the pointers to the strings in __objc_selrefs might be enough.

This helped me get closer to the compiler's output in C with:

__attribute__((section("__DATA,__objc_selrefs")))
char *const MY_SELECTOR = "hash";

Which produces:

	.section	__TEXT,__cstring,cstring_literals
L_.str:                                 ## @.str
	.asciz	"hash"

	.section	__DATA,__objc_selrefs,literal_pointers,no_dead_strip
	.globl	_MY_SELECTOR            ## @MY_SELECTOR
	.align	3
_MY_SELECTOR:
	.quad	L_.str

Unfortunately then it fails to link with "Undefined symbols for architecture x86_64: _MY_SELECTOR". But maybe it'll go better if I try in Rust.

[jrmuizel]

I recall getting a segfault on load when the method name was not in the "__objc_methname" section.

[mystor]

I threw together a simple macros 1.1-abuse crate which should generate code similar to the code which @jrmuizel posted above. It's super hacky but if you wrap it in a macro_rules! wrapper it might look OK?

I also haven't ensured that the output binary looks correct yet - so that's a thing too.

https://github.com/mystor/objc_methname

[kvark]

Heads up - we appear to suffer from this issue heavily in gfx-backend-metal.

[kvark]

I tried this piece of code in metal-rs with no success:

impl DeviceRef {
        pub fn name2(&self) -> &str { // new method
            struct Foo(*const [u8; 5]);
            unsafe impl Send for Foo {}
            unsafe impl Sync for Foo {}
     
            let s: &NSString = {
                #[no_mangle]
                #[link_section="__TEXT,__objc_methname,cstring_literals"]
                static OBJC_METH_VAR_NAME_ : [u8; 5] = *b"name\0";
                #[no_mangle]
                #[link_section="__DATA,__objc_selrefs,literal_pointers,no_dead_strip"]
                static OBJC_SELECTOR_REFERENCES_: Foo = Foo(&OBJC_METH_VAR_NAME_);
                unsafe {
                    let selector: objc::runtime::Sel = mem::transmute(OBJC_SELECTOR_REFERENCES_.0);
                    objc::__send_message(&*self, selector, ()).unwrap()
                }
            };
     
            s.as_str()
        }

        pub fn name(&self) -> &str { // old method
            unsafe {
                let name: &NSString = msg_send![self, name];
                name.as_str()
            }
        }
}

Result is:

NSForwarding: warning: selector (0x103e80630) for message name does not match selector known to Objective C runtime (0x7fff4bad3d1d)

[SSheldon]

@kvark is it certain methods being called in a tight loop that are causing a problem for gfx-backend-metal? If you can identify the methods, you could avoid this by registering the selector once and reusing it. Something like this untested code:

let sel = sel!(name);
loop {
    let name: &NSString = obj.send_message(sel, ());
}

Maybe the selectors could be loaded in a lazy static?

[kvark]

@SSheldon we are definitely considering that. It will be unfortunate to throw this out once the real static linking of selectors work out...
Speaking of which, could anyone (including @jrmuizel ) provide a small self-contained example on how that linking magic works? As I said, my little try failed because of an unknown selector.

[SSheldon]

I was never able to successfully static link a selector :/

@mystor were you seeing success with the macro crate you posted? I never got around to trying it myself.

[kvark]

We attempted to use the code @mystor provided, gone through a few iterations with them, but ended up with a linker error. The plan was to go back and try to hard-code it to see if the simplest case works. It didn't, even though for a different reason - selector being not found (run-time error).

The problem with explicit caching of sel!() is that it's hard to do without rewriting everything. We'll end up with something like a obj_class! macro that defines the methods as well as their selectors in lazy/thread-local storage. That API would be nicer than hard-coded stuff we have, but it's a large rewrite (of metal-rs crate).

[jrmuizel]

In the example you gave above the selectors are not being registered during init for some reason. I'll look into it further.

[jrmuizel]

I think it might be because of a missing __objc_imageinfo section