-
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
Add a CurrentGcx
type to let the deadlock handler access TyCtxt
#115220
Conversation
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
☔ The latest upstream changes (presumably #111713) made this pull request unmergeable. Please resolve the merge conflicts. |
2f2133c
to
db47bee
Compare
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.
cc @nnethercote as you authored #74969
pub unsafe fn access<R>(&self, f: impl for<'tcx> FnOnce(&'tcx GlobalCtxt<'tcx>) -> R) -> R { | ||
let gcx_ptr: *const GlobalCtxt<'_> = self.value.lock().unwrap() as *const _; | ||
f(unsafe { &*gcx_ptr }) | ||
} |
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.
Should we remove the TyCtxt
inside ImplicitCtxt
, and always use this to access it?
Can the unsafety be removing by tweaking enter_global_context
API?
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.
No. Unsafety could probably be removed with some blocking scheme, but our existing scheme is simple and fast.
This comment has been minimized.
This comment has been minimized.
We currently have two ways to access a |
b304272
to
3bb7aa3
Compare
CurrentGcx
type to let the deadlock handler access TyCtxt
I've changed this to use a |
compiler/rustc_interface/src/util.rs
Outdated
}); | ||
} | ||
|
||
let current_gcx = CurrentGcx::new(); | ||
let current_gcx_ = FromDyn::from(current_gcx.clone()); | ||
let current_gcx = FromDyn::from(current_gcx); |
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 naming scheme is really hard to read. There should be more than a single trailing underscore to distinguish two similar-but-different things. A comment would also be helpful to explain the distinction.
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.
They're exactly the same value. I've changed it to clone after the FromDyn
construction to make that more clear.
/// the deadlock handler is not called inside such a job. | ||
#[derive(Clone)] | ||
pub struct CurrentGcx { | ||
value: Lrc<Lock<Option<GcxPtr>>>, |
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.
GcxPtr
contains a Lrc<RwLock<Option<*const ()>>>
. Which means that CurrentGcx
is basically a Lrc<Lock<Option<Lrc<RwLock<Option<*const ()>>>>>>
.
I think this is the most complex Rust type I've ever seen. Something is very wrong here. Can it be made simpler?
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 was trying to make enter
behave well when called concurrently, but I think CurrentGcx
would have to hold a set of GcxPtr
for that to work properly. I've removed GcxPtr
and instead let enter
panic for concurrent usage.
This comment has been minimized.
This comment has been minimized.
I don't have ideas for further improvements here, and we do want to land this before rust-lang/compiler-team#681. |
I still don't like how much the |
It doesn't matter if you like it or not. It's required for correctness. |
@@ -194,27 +197,38 @@ pub(crate) fn run_in_thread_pool_with_globals<F: FnOnce() -> R + Send, R: Send>( | |||
let registry = sync::Registry::new(threads); | |||
|
|||
if !sync::is_dyn_thread_safe() { | |||
return run_in_thread_with_globals(edition, || { | |||
return run_in_thread_with_globals(edition, |current_gcx| { | |||
// Register the thread for use with the `WorkerLocal` type. |
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.
Could we make CurrentGcx
global so we don't pass it everywhere? I mean more global than tls
.
So that we can even use it to fill ImplicitCtxt
when #111522 occurs
It would be nice to have an explanation as to why this is the only solution. |
☔ The latest upstream changes (presumably #117482) made this pull request unmergeable. Please resolve the merge conflicts. |
@Zoxc any updates on this? thanks |
r? @oli-obk |
I didn't mean to imply it was the only solution. My point was that you shouldn't introduce bugs because you don't like the current code or you think the code with the bug is cleaner. I did think of a potential alternative. We could maintain a list of threads which waits on queries and when a deadlock is detected, the deadlock handler would pick a thread to wake up and designate it to process cycles. That would get rid of the unsafe and the thread in the deadlock handler. |
@bors delegate+ r=me after a rebase. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (c5e7f45): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 669.029s -> 669.68s (0.10%) |
This brings back
GCX_PTR
(previously removed in #74969) allowing the deadlock handler access toGlobalCtxt
. This fixes #111522.r? @cjgillot