-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Make OnDiskCache thread-safer #49396
Conversation
@@ -604,6 +610,7 @@ impl<'a, 'tcx, 'x> SpecializedDecoder<interpret::AllocId> for CacheDecoder<'a, ' | |||
this.with_position(shorthand, |this| interpret::AllocId::decode(this)) | |||
} | |||
)?; | |||
// FIXME: Looks like overwrites aren't allowed here |
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 could asseet that the result is the same. That would be fine I guess.
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.
That won't work for the alloc cache though. This code was not written with threading in mind. I think it could work if you made the creation of the alloc_id atomic with the insertion into the cache. But then you'd be back at troubles with the end position. So if there's an entry in the alloc_cache but not the end position, you need to decode the allocation, but throw away the result in order to make the deserializer move forward.
Uuuuh. It's a little messy but should be doable. You wanna do a live hacking together to hash out the details or is the above info enoughfor you?
I removed the Miri parts of this PR. The on disk cache for alloc IDs doesn't seem to actually work on |
b94e5af
to
174521f
Compare
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
6daf665
to
e1498b3
Compare
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Ping from triage, @michaelwoerister ! |
file_index_to_file: RefCell<FxHashMap<FileMapIndex, Lrc<FileMap>>>, | ||
synthetic_expansion_infos: RefCell<FxHashMap<AbsoluteBytePos, SyntaxContext>>, | ||
file_index_to_file: Lock<FxHashMap<FileMapIndex, Lrc<FileMap>>>, | ||
synthetic_expansion_infos: Lock<FxHashMap<AbsoluteBytePos, SyntaxContext>>, |
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 two fields are locked for every span value that's encoded. I wonder if we can do better here. They are just simple caches.
@@ -866,7 +866,7 @@ pub struct GlobalCtxt<'tcx> { | |||
maybe_unused_extern_crates: Vec<(DefId, Span)>, | |||
|
|||
// Internal cache for metadata decoding. No need to track deps on this. | |||
pub rcache: RefCell<FxHashMap<ty::CReaderCacheKey, Ty<'tcx>>>, | |||
pub rcache: Lock<FxHashMap<ty::CReaderCacheKey, Ty<'tcx>>>, |
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 field is also used very often, also during metadata encoding. Might be a good candidate for a thread-local cache in the future.
I've added an item to #48685 about making those fields thread-locals. |
I made use of |
☔ The latest upstream changes (presumably #49390) made this pull request unmergeable. Please resolve the merge conflicts. |
9b7a707
to
4f32dda
Compare
Looks good to me. r=me with the overlap with #49558 resolved. |
☔ The latest upstream changes (presumably #49558) made this pull request unmergeable. Please resolve the merge conflicts. |
4f32dda
to
fa06023
Compare
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
fa06023
to
807c1a0
Compare
@bors r=michaelwoerister |
📌 Commit 807c1a0 has been approved by |
…oerister Make OnDiskCache thread-safer I'm not sure if `synthetic_expansion_infos` is handled correctly. `interpret_alloc_cache` and `interpret_alloc_size` seems to be wrong though, since the code may now decode two `AllocId`s in parallel. I'd like some input on how to fix that. cc @oli-obk r? @michaelwoerister
Make OnDiskCache thread-safer I'm not sure if `synthetic_expansion_infos` is handled correctly. `interpret_alloc_cache` and `interpret_alloc_size` seems to be wrong though, since the code may now decode two `AllocId`s in parallel. I'd like some input on how to fix that. cc @oli-obk r? @michaelwoerister
☀️ Test successful - status-appveyor, status-travis |
I'm not sure if
synthetic_expansion_infos
is handled correctly.interpret_alloc_cache
andinterpret_alloc_size
seems to be wrong though, since the code may now decode twoAllocId
s in parallel. I'd like some input on how to fix that.cc @oli-obk
r? @michaelwoerister