Struct CurrentDepGraph

pub(super) struct CurrentDepGraph<D: Deps> {
    encoder: GraphEncoder<D>,
    anon_node_to_index: ShardedHashMap<DepNode, DepNodeIndex>,
    fingerprints: Lock<IndexVec<DepNodeIndex, Option<Fingerprint>>>,
    forbidden_edge: Option<EdgeFilter>,
    nodes_in_current_session: Option<Lock<FxHashMap<DepNode, DepNodeIndex>>>,
    anon_id_seed: Fingerprint,
    total_read_count: AtomicU64,
    total_duplicate_read_count: AtomicU64,
}

CurrentDepGraph stores the dependency graph for the current session. It will be populated as we run queries or tasks. We never remove nodes from the graph: they are only added.

The nodes in it are identified by a DepNodeIndex. We avoid keeping the nodes in memory. This is important, because these graph structures are some of the largest in the compiler.

For this reason, we avoid storing DepNodes more than once as map keys. The anon_node_to_index map only contains nodes of anonymous queries not in the previous graph, and we map nodes in the previous graph to indices via a two-step mapping. SerializedDepGraph maps from DepNode to SerializedDepNodeIndex, and the prev_index_to_index vector (which is more compact and faster than using a map) maps from SerializedDepNodeIndex to DepNodeIndex.

This struct uses three locks internally. The data, anon_node_to_index, and prev_index_to_index fields are locked separately. Operations that take a DepNodeIndex typically just access the data field.

We only need to manipulate at most two locks simultaneously: anon_node_to_index and data, or prev_index_to_index and data. When manipulating both, we acquire anon_node_to_index or prev_index_to_index first, and data second.

Fields

encoder: GraphEncoder<D>

anon_node_to_index: ShardedHashMap<DepNode, DepNodeIndex>

fingerprints: Lock<IndexVec<DepNodeIndex, Option<Fingerprint>>>

This is used to verify that fingerprints do not change between the creation of a node and its recomputation.

forbidden_edge: Option<EdgeFilter>

Used to trap when a specific edge is added to the graph. This is used for debug purposes and is only active with debug_assertions.

nodes_in_current_session: Option<Lock<FxHashMap<DepNode, DepNodeIndex>>>

Used to verify the absence of hash collisions among DepNodes. This field is only Some if the -Z incremental_verify_ich option is present or if debug_assertions are enabled.

The map contains all DepNodes that have been allocated in the current session so far.

anon_id_seed: Fingerprint

Anonymous DepNodes are nodes whose IDs we compute from the list of their edges. This has the beneficial side-effect that multiple anonymous nodes can be coalesced into one without changing the semantics of the dependency graph. However, the merging of nodes can lead to a subtle problem during red-green marking: The color of an anonymous node from the current session might “shadow” the color of the node with the same ID from the previous session. In order to side-step this problem, we make sure that anonymous NodeIds allocated in different sessions don’t overlap. This is implemented by mixing a session-key into the ID fingerprint of each anon node. The session-key is just a random number generated when the DepGraph is created.

total_read_count: AtomicU64

These are simple counters that are for profiling and debugging and only active with debug_assertions.

total_duplicate_read_count: AtomicU64

Implementations

impl<D: Deps> CurrentDepGraph<D>

fn new( session: &Session, prev_graph_node_count: usize, encoder: FileEncoder, record_graph: bool, record_stats: bool, previous: Arc<SerializedDepGraph>, ) -> Self

fn record_edge( &self, dep_node_index: DepNodeIndex, key: DepNode, fingerprint: Fingerprint, )

fn alloc_node( &self, key: DepNode, edges: EdgesVec, current_fingerprint: Fingerprint, ) -> DepNodeIndex

Writes the node to the current dep-graph and allocates a DepNodeIndex for it. Assumes that this is a node that has no equivalent in the previous dep-graph.

fn debug_assert_not_in_new_nodes( &self, prev_graph: &SerializedDepGraph, prev_index: SerializedDepNodeIndex, )

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 512 bytes