-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[runtime] move the empty Dictionary and Set singletons to rodata #5850
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,6 +26,14 @@ namespace swift { | |
// _direct type metadata for Swift._EmptyArrayStorage | ||
SWIFT_RUNTIME_STDLIB_INTERFACE | ||
extern "C" ClassMetadata _TMCs18_EmptyArrayStorage; | ||
|
||
// _direct type metadata for Swift._RawNativeDictionaryStorage | ||
SWIFT_RUNTIME_STDLIB_INTERFACE | ||
extern "C" ClassMetadata _TMCs27_RawNativeDictionaryStorage; | ||
|
||
// _direct type metadata for Swift._RawNativeSetStorage | ||
SWIFT_RUNTIME_STDLIB_INTERFACE | ||
extern "C" ClassMetadata _TMCs20_RawNativeSetStorage; | ||
} | ||
|
||
swift::_SwiftEmptyArrayStorage swift::_swiftEmptyArrayStorage = { | ||
|
@@ -41,6 +49,62 @@ swift::_SwiftEmptyArrayStorage swift::_swiftEmptyArrayStorage = { | |
} | ||
}; | ||
|
||
|
||
|
||
swift::_SwiftEmptyDictionaryStorage swift::_swiftEmptyDictionaryStorage = { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you mark this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Want me to do that to the existing Array decl too? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes please. :-) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Argh:
Any bright ideas, or are we forced to give up here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also: |
||
// HeapObject header; | ||
{ | ||
&_TMCs27_RawNativeDictionaryStorage, // isa pointer | ||
}, | ||
|
||
// _SwiftDictionaryBodyStorage body; | ||
{ | ||
// We set the capacity to 1 so that there's an empty hole to search. | ||
// Any insertion will lead to a real storage being allocated, because | ||
// Dictionary guarantees there's always another empty hole after insertion. | ||
1, // int capacity; | ||
0, // int count; | ||
|
||
// _SwiftUnsafeBitMap initializedEntries | ||
{ | ||
&swift::_swiftEmptyDictionaryStorage.entries, // unsigned int* values; | ||
1 // int bitCount; (1 so there's something for iterators to read) | ||
}, | ||
|
||
(void*)1, // void* keys; (non-null garabage) | ||
(void*)1 // void* values; (non-null garbage) | ||
}, | ||
|
||
0 // int entries; (zero'd bits) | ||
}; | ||
|
||
|
||
swift::_SwiftEmptySetStorage swift::_swiftEmptySetStorage = { | ||
// HeapObject header; | ||
{ | ||
&_TMCs20_RawNativeSetStorage, // isa pointer | ||
}, | ||
|
||
// _SwiftDictionaryBodyStorage body; | ||
{ | ||
// We set the capacity to 1 so that there's an empty hole to search. | ||
// Any insertion will lead to a real storage being allocated, because | ||
// Dictionary guarantees there's always another empty hole after insertion. | ||
1, // int capacity; | ||
0, // int count; | ||
|
||
// _SwiftUnsafeBitMap initializedEntries | ||
{ | ||
&swift::_swiftEmptySetStorage.entries, // unsigned int* values; | ||
1 // int bitCount; (1 so there's something for iterators to read) | ||
}, | ||
|
||
(void*)1 // void* keys; (non-null garabage) | ||
}, | ||
|
||
0 // int entries; (zero'd bits) | ||
}; | ||
|
||
static __swift_uint64_t randomUInt64() { | ||
#if defined(__APPLE__) | ||
return static_cast<__swift_uint64_t>(arc4random()) | | ||
|
Uh oh!
There was an error while loading. Please reload this page.
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.
This is pretty awful and we should stop doing it [later]. Maybe we can make some rule about classes containing exactly one member, which could then be defined as a C struct in SwiftShims.
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.
These classes don't contain exactly one member; I'm not sure what you're picturing?
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.
Oh. You're picturing defining it only once in Stubs, and then importing it into Swift?
Should work... what special rule is needed?
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.
You'd need some rule that promises that the layout algorithm is what you expect, i.e. that the single member immediately follows the retain count header (modulo any alignment requirements), even given the empty superclass. I can't see what layout algorithm wouldn't do this, but then again @slavapestov recently discovered that our ObjC layout wasted 8 bytes for no particular reason on certain classes, so...
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 definitely plan for the compiler to be allowed to reorder class and struct members, though.
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.
Ok wait does putting this stuff in rodata even make sense? The reference count has to be mutable, right?
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.
Yeah, and even then it couldn't be in true const memory anyway because it contains absolute addresses that would need to be relocated at load time (until libswiftCore lives in the dyld shared cache, at least).
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.
I still think it'd be nice to put the Swift compiler in charge of emitting these objects instead of C++ code. Doesn't seem like it'd be terribly difficult to wire up, if you want to take a shot at it.
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.
In the interest of incremental improvement, are you fine with moving forward with this PR as-is for now? The Dictionary/Array layouts at this level in the system are basically finalized, so the only thing that could break these are someone implementing a new class layout algorithm.
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.
Sure, I have no problem taking this patch in its current state.