Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-13469] Call to objc_opt_self slows access to non-generic class metadata #55911

Open
belkadan opened this issue Aug 28, 2020 · 1 comment
Open
Labels
compiler The Swift compiler in itself improvement performance

Comments

@belkadan
Copy link
Contributor

Previous ID SR-13469
Radar rdar://problem/68115905
Original Reporter @belkadan
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement
Assignee None
Priority Medium

md5: d1188f5ba806808d599c07bf84d7d805

relates to:

  • SR-13459 type metadata accessor for private swift-native class should be a single memory access

Issue Description:

On Apple platforms, non-generic class metadata still has to be registered with the ObjC runtime upon first use, just in case it escapes into Objective-C-land. The current strategy to do this is to send a dummy message to it, which new enough ObjC runtimes provide in the form of an objc_opt_self function (equivalent to [theClass self]). However, even this optimized function is still slower than checking a static (once-initialized) flag (see SR-13459).

While the compiler is generally very good about optimizing repeated accesses to metadata, there are (apparently) cases where the dummy function call to objc_opt_self is still unnecessarily expensive. This could be remedied by guarding it with an (unsynchronized) guard variable in the metadata accessor:

if (!isMyClassRegisteredWithObjC.load(std::memory_order::relaxed)) {
  objc_opt_self(MyClass);
  isMyClassRegisteredWithObjC.store(true, std::memory_order::relaxed);
}

In fact, if we want to expose a bit of ObjC's ABI, we could check the very flag in an Objective-C class that checks for initialization, or do something similar like "does the data pointer still point to read-only data". But I'm not sure if Apple wants to sign up for that.

The main caveat I can think of is larger code size, so it's possible we don't want to do this in -Osize mode.

@typesanitizer
Copy link

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself improvement performance
Projects
None yet
Development

No branches or pull requests

3 participants