Use more fine grained locks for the dep graph#63756
Conversation
src/librustc/dep_graph/graph.rs
Outdated
There was a problem hiding this comment.
@michaelwoerister I'm guessing you're the person to ask about this.
There was a problem hiding this comment.
At some point we had debug output for incremental compilation that was using this. If it is really unused now, you can remove it.
|
The job 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 |
80d3457 to
bc5ac9c
Compare
michaelwoerister
left a comment
There was a problem hiding this comment.
Thanks for the PR, @Zoxc!
The changes look correct to me. Do we have evidence that they improve performance?
bc5ac9c to
9972c69
Compare
This PR probably doesn't help. It's just a prerequisite for other stuff which does improve performance. |
|
Ping from triage: |
|
Ping from triage Thanks. |
|
Ping from triage: @aturon could you review this PR? |
|
Ping from Triage: Pinging @aturon one more time. |
|
@aturon is stepping back from this role, we should reassign all PRs assigned to them. |
There was a problem hiding this comment.
Looks good overall. I have one nit, which is a request to document the overall pattern on CurrentDepGraph.
In general, we discussed this PR a bit in our "parallel sync meeting" today and the general conclusion was that -- in the future -- it might be nice to extract the CurrentDepGraph code into its own module, so that it can have a smaller "abstraction boundary", but since this is part of a larger series of PRs it doesn't make sense to do it now.
We also mentioned using SeqCst everywhere unless there's a strong reason to do otherwise (which doesn't seem to apply here, but @Mark-Simulacrum already noted that here).
src/librustc/dep_graph/graph.rs
Outdated
There was a problem hiding this comment.
The comment below is great -- but it'd be good to document just a bit more (this is pre-existing, as the code wasn't all that thoroughlly commented before =)
I'd say something like:
Encodes the rustc dependency graph. The nodes are identified by an index (DepNodeIndex); the data for each node is stored in its DepNodeData, found in the data field.
We never remove nodes from the graph: they are only added. Most of the time, the node is mapped 1-to-1 with some DepNode, which basically identifies a query. When such nodes are allocated, we add the DepNod into the node_to_node_index map and allocate a fresh node index.
This struct uses two locks internally: the data and node_to_node_index field are locked separately. Operations that begin with a DepNodeIndex typically just access the data field.
The only operation that must manipulate both fields is adding new nodes, in which case we first acquire the node_to_node_index lock and then, once a new node is to be inserted, acquire the lock on data.
(We also have a field fields that use atomics: these are simple counters that are used for profiling and debugging and are not used with debug_assertions.)
There was a problem hiding this comment.
I added that, but removed the incorrect parts =P
|
r=me with comment + SeqCst nits applied =) |
|
☔ The latest upstream changes (presumably #65209) made this pull request unmergeable. Please resolve the merge conflicts. |
9ee2119 to
89c6415
Compare
89c6415 to
b6a5740
Compare
|
@bors r=nikomatsakis |
|
📌 Commit b6a5740 has been approved by |
Use more fine grained locks for the dep graph Split out from #61845. r? @michaelwoerister cc @aturon
|
☀️ Test successful - checks-azure |
…sakis Use a sharded dep node to dep node index map Split out from rust-lang#61845 and based on rust-lang#63756. r? @nikomatsakis
…sakis Use a sharded dep node to dep node index map Split out from rust-lang#61845 and based on rust-lang#63756. r? @nikomatsakis
…sakis Use a sharded dep node to dep node index map Split out from rust-lang#61845 and based on rust-lang#63756. r? @nikomatsakis
…sakis Use a sharded dep node to dep node index map Split out from rust-lang#61845 and based on rust-lang#63756. r? @nikomatsakis
Split out from #61845.
r? @michaelwoerister cc @aturon