-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Update fast dealloc to use new-style interposing and support objc weak refs #25864
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
Update fast dealloc to use new-style interposing and support objc weak refs #25864
Conversation
dcb5b70
to
1ddba98
Compare
@swift-ci please test |
Build failed |
@swift-ci please test |
Build failed |
Build failed |
@swift-ci please test |
Build failed |
Build failed |
@swift-ci please test |
Build failed |
Build failed |
@swift-ci please test |
Build failed |
Build failed |
Ok, looks like we're still at "weak interop fails on i386 simulator only", which is interesting |
bb516a0
to
24a08b4
Compare
@swift-ci please test |
@swift-ci please smoke benchmark |
Performance: -O
Code size: -OPerformance: -Osize
Code size: -OsizePerformance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
Perf still looks good 👍 |
Build failed |
Build failed |
Neat! @mikeash, it looks like the only tests that failed were the ones that would need objc runtime support (which look good locally). I think this might be ready! |
@swift-ci please test |
Build failed |
Build failed |
Surprisingly, the 32 bit sim failure looks unrelated to this change. |
As is the linux failure |
@swift-ci please test |
Build failed |
@swift-ci please test |
Build failed |
@swift-ci please test os x platform |
Build failed |
@swift-ci please test |
Build failed |
Build failed |
e0b0646
to
ba77426
Compare
ba77426
to
f36a4db
Compare
@swift-ci please test |
Build failed |
Build failed |
} | ||
|
||
LLVM_ATTRIBUTE_ALWAYS_INLINE | ||
void setIsImmortal(bool value) { | ||
setField(IsImmortal, value); | ||
assert(value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If value must be true, should this even take a parameter?
@@ -369,33 +388,56 @@ class RefCountBitsT { | |||
enum Immortal_t { Immortal }; | |||
|
|||
LLVM_ATTRIBUTE_ALWAYS_INLINE | |||
bool isImmortal() const { | |||
return bool(getField(IsImmortal)); | |||
bool isImmortal(bool checkSlowRCBit) const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is always called with a constant true
or false
, it might be clearer to just split it into two functions.
static bool _check_fast_dealloc() { | ||
//This will always be in libobjc, so RTLD_DEFAULT won't have to do an | ||
//expensive search in practice | ||
return dlsym(RTLD_DEFAULT, "_objc_has_weak_formation_callout") != nullptr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're using RTLD_NEXT
in a couple of other places, which ensures we don't go off looking at a ton of other dylibs.
Fixes rdar://problem/36825362