A module dependency graph incremental loading method and system

Abstract

The application discloses a kind of module dependency graph incremental loading method and system, belong to computer software running loading technical field.The method obtains construction period dependency information and running period dependency feedback, generates and fuses double-state dependency graph;Double-state dependency graph is fragmented and boundary abstract is generated, and is persisted as benchmark snapshot and incremental log;Response entry module loading request, load target fragment and necessary dependency closure fragment, and with ghost node expression remote fragment not expanded temporarily;When cross-fragment access, check ghost node and expand remote fragment;In shadow graph, apply incremental log and carry out consistency check, replace current graph view by atom after, generate module loading list.The application can reduce graph reading amount and memory occupation, reduce repeated log playback, improve graph view consistency under the scene of module hot update and multi-version operation.

Description

Technical Field

[0001] This invention relates to the field of computer software runtime loading technology, specifically to a method and system for incremental loading of module dependency graphs. Background Technology

[0002] In large-scale plug-in business platforms, micro-frontend platforms, modular service platforms, or algorithm component runtime platforms, it is typically necessary to determine the corresponding modules and their dependent modules based on the entry module loading request, and generate a module loading list according to the dependencies between modules. Existing module loading technologies can construct module dependency graphs based on module declaration files, static import statements, resource lists, configuration files, or interface definition files, and calculate the module loading order accordingly. Some technologies can also combine block loading or lazy loading methods to reduce the load pressure on module resources.

[0003] However, existing technologies typically focus more on optimizing the loading of module files, script resources, or build artifacts, while neglecting the incremental loading and consistency management of the module dependency graph itself. As the number of modules, module versions, and dynamic expansion capabilities continue to increase, in addition to static dependencies during the build phase, new runtime dependencies will arise between modules due to dynamic imports, reflection loading, conditional branch triggering, runtime resource access, or plugin calls. If the module loading list is generated solely based on build-phase dependency information, it is easy to miss dependency edges that occur during actual runtime, thereby affecting the completeness and accuracy of the module loading results.

[0004] Furthermore, during entry module loading, cross-shard dynamic dependency access, or module hot update, the lack of shard boundary verification, runtime dependency feedback fusion, incremental log replay, and atomic switching mechanism for the module dependency graph itself can easily lead to a large graph reading range, high memory consumption, and numerous duplicate log replays. It may also result in inconsistent graph views read by different loading requests during module hot update.

[0005] Therefore, a method and system for incremental loading of module dependency graphs are needed. This method should be able to load necessary graph fragments based on the entry module's loading request without fully loading the entire module dependency graph. It should also perform lightweight representation and verification of remote graph fragments that do not need to be expanded immediately. This would reduce graph reading volume and memory usage, and improve graph visibility during cross-fragment dependency access and module hot update processes. Figure 1 To the point of being responsive. Summary of the Invention

[0006] This invention aims to provide a method and system for incremental loading of module dependency graphs, in order to solve the technical problems of large modular operating platforms needing to repeatedly load the complete dependency graph during entry module loading, cross-shard dynamic dependency access, and module hot updates, resulting in large cold start graph reading volume, high memory consumption, numerous duplicate log replays, and inconsistent graph views during hot updates.

[0007] To achieve the above objectives, the present invention provides a method for incremental loading of module dependency graphs, comprising the following steps: Obtain dependency information during the build phase and dependency feedback during the runtime phase, generate a first dependency graph and a second dependency graph, and fuse them to obtain a bi-state dependency graph; The bistate dependency graph is segmented to obtain multiple graph segments. A boundary summary is generated for each graph segment, and the graph segments and the boundary summaries are saved as a baseline snapshot and an incremental log. Receive an entry module loading request, which includes an entry module identifier and an entry module version; determine the target map fragment based on the entry module identifier and the entry module version; read the baseline snapshot and necessary incremental log segments of the target map fragment; and replay the necessary incremental log segments to obtain the current state of the target map fragment. Based on the dependency edges, loading constraints, and version constraints in the current state, necessary dependency closure fragments are loaded, and boundary summaries are read for remote graph fragments that are not yet expanded during the current entry module loading phase. Ghost nodes are created to form the current graph view. In response to cross-shard dependency access, the system performs verification based on the boundary summary, version vector, interface constraints, and loading constraints stored in the ghost node. If the verification passes, it reads the baseline snapshot and necessary incremental log segments of the remote graph shard and replaces the ghost node with the remote graph shard. Create a shadow graph, apply incremental logs to the shadow graph and perform consistency checks. After the checks pass, replace the graph view with the new current graph view corresponding to the shadow graph, and generate a module loading list based on the new current graph view.

[0008] Furthermore, the build-time dependency information is obtained by parsing module declaration files, static import statements, resource lists, configuration files, build scripts, interface definition files, or build artifact summaries; the runtime dependency feedback is collected by the module loader probe during the module parsing, module instantiation, module import, module execution, resource access, cache reading, or loading exception handling stages.

[0009] Furthermore, generating the second dependency graph includes: determining the actual module dependencies that occur during runtime based on runtime dependency feedback; marking dependency edges that do not exist in the first dependency graph as dynamic dependency edges or missing dependency edges; and writing the corresponding dependency edges into the incremental log or marking them as candidate deletion edges based on the dynamic dependency confidence.

[0010] Furthermore, when partitioning the bi-state dependency graph, strong connected component analysis is first performed on the bi-state dependency graph to divide the module nodes with cyclic dependencies into the same candidate partition. Then, the candidate partitions are merged or split by combining the entry module, version vector and partition size threshold.

[0011] Furthermore, the boundary summary includes at least the cross-shard outgoing edge summary, cross-shard incoming edge summary, interface signature summary, structural fingerprint, load constraint summary, and version vector; when generating the boundary summary, the cross-shard outgoing edge set, cross-shard incoming edge set, exported interface signature set, version vector, and load constraint set are subjected to field normalization processing.

[0012] Furthermore, when replaying the necessary incremental log segments, it is determined whether the pre-change summary in the incremental log to be replayed is consistent with the current fragment summary recalculated from the node set, edge set, and boundary summary of the current graph fragment; if consistent, the incremental log is applied and a post-change summary is generated; if inconsistent, replay is stopped and the corresponding graph fragment is marked as requiring shadowing. Figure 1 Consistent updates.

[0013] Furthermore, when loading the necessary dependency closure fragments, the target fragments corresponding to strong dependencies, critical path dependencies, immediately invoked interface dependencies, version-constrained dependencies, or dependencies that do not allow lazy loading are determined as necessary dependency closure fragments; weak dependencies, conditional dependencies, or remote graph fragments that do not need to be expanded during the current entry module loading stage are represented as ghost nodes.

[0014] Furthermore, the ghost node includes a remote shard identifier, a remote shard version, a remote shard boundary summary, a remote shard version vector, interface constraints, loading constraints, expansion status, and an incremental log index.

[0015] Furthermore, the consistency verification includes loop convergence verification, interface compatibility verification, version consistency verification, boundary summary consistency verification, and load constraint satisfiability verification. After the verification passes, load requests that have obtained an old current graph view reference continue to use the old current graph view, and new load requests use the new current graph view. If the verification fails, the current graph view is not replaced.

[0016] The present invention also provides a module dependency graph incremental loading system, comprising: The dual-state dependency graph generation module is used to obtain dependency information during the build phase and dependency feedback during the runtime phase, generate a first dependency graph and a second dependency graph, and fuse them to obtain a dual-state dependency graph. The graph segmentation and summarization module is used to segment bi-state dependency graphs and generate boundary summaries of the graph segments; The snapshot log management module is used to persist graph fragments as baseline snapshots and incremental logs, and provides the baseline snapshot and necessary incremental log segments for the target graph fragment; The entry incremental loading module is used to respond to the entry module loading request, load the target graph fragment, necessary dependency closure fragments, and boundary summaries of unloaded remote graph fragments, and create ghost nodes to form the current graph view; The delayed unfolding feedback module is used to respond to cross-shard dependency access, perform boundary summary verification on the remote graph shard corresponding to the ghost node, and unfold the remote graph shard when the verification passes. The consistency update scheduling module is used to atomically replace the current graph view after the shadow graph passes the consistency check, and generate a module loading list.

[0017] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention generates a bi-state dependency graph by integrating dependency information during the construction phase and dependency feedback during the runtime phase. This enables module dependencies to simultaneously reflect the static dependencies determined during the construction phase and the dynamic dependencies that actually occur during the runtime phase. This reduces the risk of missing dependency edges in scenarios such as dynamic import, reflection loading, conditional loading, or runtime resource access, and improves the accuracy of module loading list generation. 2. This invention segments the bi-state dependency graph and generates boundary summaries for the graph segments. When the entry module is loaded, only the target graph segment and the necessary dependency closure segment are loaded. For the remote graph segments that do not need to be expanded, their verifiable boundary states are saved as ghost nodes, thereby reducing the amount of reading of the complete module dependency graph during the cold start phase and reducing memory usage. 3. This invention records graph fragment changes through baseline snapshots and incremental logs. When loading the graph or accessing cross-fragment dependencies, it only reads the baseline snapshot of the corresponding graph fragment and replays the necessary incremental log segments, avoiding repeated parsing of all modules and repeated construction of the complete dependency graph, thereby reducing repeated log replay and repeated I / O overhead. 4. When module versions change, modules are hot-updated, or runtime dependency edges are missing, this invention first applies incremental logs to the shadow graph and performs consistency checks. After the checks pass, the current graph view is atomically replaced. This ensures that loading requests that have already obtained the old graph view continue to use it, while newly initiated loading requests use the new graph view. This improves the graph view performance in scenarios involving hot module updates and multiple versions. Figure 1 To the point of being responsive. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an incremental loading method for module dependency graphs according to the present invention. Figure 2 This is a schematic diagram of the structure of a module dependency graph incremental loading system according to the present invention; Figure 3 This is a schematic diagram illustrating the relationship between map fragmentation, boundary summaries, and ghost nodes in this invention; Figure 4 The baseline snapshot, incremental log, and shadow in this invention Figure 1 A schematic diagram of the homogeneous update process. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] This invention treats the module dependency graph itself as an object to be incrementally loaded and managed for consistency, rather than simply using the module dependency graph as a static basis for calculating the module loading order. Specifically, this invention achieves partial loading, on-demand expansion, and secure updates of the module dependency graph through graph fragmentation, boundary summaries, ghost nodes, baseline snapshots, incremental logs, runtime feedback, and two-stage updates of shadow graphs.

[0021] Example 1: like Figure 1 As shown, this embodiment provides a module dependency graph incremental loading method, which is applied to a module runtime platform; the module runtime platform is used to manage multiple modules and load the corresponding modules according to the entry module loading request.

[0022] Modules can be code modules, plugin modules, business components, resource packages, algorithm components, script units, service units, or combinations thereof; there can be compilation dependencies, runtime dependencies, resource dependencies, data dependencies, event dependencies, interface dependencies, version dependencies, or conditional dependencies between modules.

[0023] The method in this embodiment includes the following steps: S1: Obtain build-time dependency information and runtime dependency feedback, and fuse them to generate a bi-state dependency graph. In this step, the module runtime platform first obtains the build-time dependency information.

[0024] Build-time dependency information can be obtained by parsing module declaration files, static import statements, resource manifests, configuration files, build scripts, interface definition files, and build artifact summaries.

[0025] The module declaration file describes the module name, module identifier, module version, imported modules, exported interfaces, runtime environment constraints, and resource reference relationships; static import statements describe the dependencies determined during compilation or packaging; the resource manifest describes the images, styles, configurations, model files, or other resource files required for the module to run; the exported interface signature describes the interface name, parameter type, return type, and interface version provided by the module to other modules; and the build artifact summary identifies whether the module's build result has changed.

[0026] The module runtime platform generates a first dependency graph based on the above build-time dependency information; the first dependency graph uses modules as nodes and build-time dependencies between modules as edges.

[0027] The nodes in the first dependency graph include module identifiers and module versions; preferably, the nodes also include build artifact summaries, export interface signatures, import interface signatures, resource inventory hashes, module file sizes, estimated memory usage, build timestamps, and runtime environment constraints.

[0028] The edges in the first dependency graph include the source module identifier and the target module identifier; preferably, the edges also include dependency type, version constraint, loading constraint, interface constraint, whether it is a strong dependency, whether it is a conditional dependency, and whether lazy loading is allowed.

[0029] Meanwhile, the module runtime platform collects runtime dependency feedback through the module loader probe during runtime; the module loader probe can be set in the module parsing stage, module instantiation stage, module import stage, module execution stage, resource access stage, cache reading stage, or loading exception handling stage.

[0030] Runtime dependency feedback includes dependencies generated by dynamic imports, dependencies generated by reflection loading, dependencies triggered by conditional branches, runtime resource access dependencies, actual module loading time, module cache hit status, graph shard cache hit status, missing dependency edges, interface signature mismatch events, version conflict events, circular dependency exceptions, and cross-shard access counts.

[0031] The module runtime platform generates a second dependency graph based on runtime dependency feedback; the second dependency graph is based on the actual module dependency relationships that occur during runtime and is used to supplement or correct the first dependency graph.

[0032] When generating the second dependency graph, the system sets dynamic dependency confidence for dynamic dependency edges discovered during runtime; for any dynamic dependency edge... Its dynamic dependency confidence Calculate using the following formula: .

[0033] in, For dynamic dependency edges The number of triggers within the sliding time window T. To normalize the trigger count threshold, The time decay factor corresponding to the most recent trigger time. This is the ratio of the number of times the target module was successfully loaded within the sliding time window T to the total number of times the target module was loaded. To trigger the normalized value of the number of entry modules for this dynamic dependency edge, For events such as interface signature mismatch, version conflict, or loading failure, the normalized value is... This is a flag indicating that the target module version is invalid. to These are non-negative weight parameters, and .

[0034] Subsequently, the module runtime platform merges the first dependency graph and the second dependency graph to generate a bi-state dependency graph.

[0035] For nodes that exist in both the first and second dependency graphs, the system merges the node's build-time and runtime attributes; for dependency edges that exist in the first dependency graph but are not triggered in the second dependency graph, the system retains the static attributes of the dependency edge and records its runtime hit status; for dependency edges that exist in the second dependency graph but not in the first dependency graph, the system marks the dependency edge as a dynamic dependency edge discovered at runtime or a missing dependency edge.

[0036] When dynamic dependency edge Dynamic dependency confidence Greater than or equal to the new threshold And if no interface signature mismatch or version conflict occurs within K consecutive running windows, the system determines the dynamic dependency edge as a writable edge and generates an incremental log containing the transaction number, shard identifier, operation object identifier, pre-change summary, post-change summary, and version vector, enabling the dynamic dependency edge to participate in subsequent graph shard updates; when Less than or equal to the deletion threshold If the target module version is invalid, the system marks the dynamic dependency edge as a candidate for deletion and only deletes it in the shadow. Figure 1 Update the current spectrum view after the consistency check passes.

[0037] Among them, the sliding time window T, the number of continuously running windows K, and the new threshold Deletion threshold and weight parameters to It can be pre-configured according to the scale of the module's operating platform; preferably, Greater than This is to create a hysteresis interval and prevent dynamic dependent edges from being frequently added or deleted due to short-term fluctuations.

[0038] The input parameters for the aforementioned dynamic dependency confidence are all derived from runtime state data generated within the module loader and are normalized before being used for graph update control; when Greater than or equal to the new threshold When this happens, the system will write the corresponding dynamic dependency edge to the incremental log or increase the expansion priority of its corresponding graph fragment; when Less than or equal to the deletion threshold or When the value is 1, the system marks the corresponding dynamically dependent edge as a candidate for deletion, but does not directly modify the current graph view; instead, it does so in the shadow. Figure 1 Update after consistency check passes.

[0039] The dynamic dependency confidence is used as a graph update control variable within the module loader to control whether dynamic dependency edges are written to the incremental log, whether they participate in graph sharding updates, whether they affect the priority of ghost node expansion, and whether they participate in the generation of the module loading list and prefetching order. The dynamic dependency confidence is not used for recommending, evaluating, classifying, or making decisions about natural persons, user groups, transaction objects, or content.

[0040] Therefore, the bi-state dependency graph contains both static dependency information determined during the construction phase and dynamic dependency information actually fed back during the runtime, which can more accurately represent the actual dependency relationships between modules.

[0041] S2, segments the bistate dependency graph and generates boundary summaries for each graph segment. In this step, the module runtime platform performs fragmentation on the bi-state dependency graph to obtain multiple graph fragments.

[0042] Graph fragments are local data units of a bimorphic dependent graph; each graph fragment includes the set of nodes within the fragment, the set of edges within the fragment, the set of outgoing edges across fragments, the set of incoming edges across fragments, and fragment metadata.

[0043] The system segments the bimorphic dependency graph according to strongly connected components, entry modules, routing domains, business domains, namespaces, version vectors, build artifact groups, tenant identifiers, and deployment regions.

[0044] In a preferred embodiment, the system first performs strong connected component analysis on the bistate dependency graph, and divides multiple module nodes with cyclic or close dependencies into the same candidate fragment; then, the system combines the entry module, routing domain, version vector and fragment size threshold to merge or split the candidate fragments to obtain multiple final graph fragments.

[0045] By adopting the above method, modules with close dependencies can be placed in the same graph fragment as much as possible, reducing cross-fragment access during runtime; at the same time, it can also avoid the fragment loading granularity from becoming too large for a single graph fragment.

[0046] Each graph shard has shard metadata; the shard metadata includes shard identifier, shard version, number of nodes in the shard, number of edges in the shard, set of entry modules for the shard, set of outgoing edges across shards, set of incoming edges across shards, shard size, historical shard loading time, shard cache status, version vector, and update timestamp.

[0047] After the map is segmented, the system generates a boundary summary for each map segment.

[0048] Boundary summaries are used to determine whether a remote graph fragment satisfies the interface constraints, version constraints, and loading constraints of the current cross-fragment dependency access without loading the complete remote graph fragment.

[0049] Boundary digests include cross-shard outgoing edge digests, cross-shard incoming edge digests, interface signature digests, structural fingerprints, and version vectors; preferably, boundary digests may also include build artifact digests, load constraint digests, resource constraint digests, dependency type digests, dynamic dependency confidence digests, and digest generation time.

[0050] Among them, the cross-shard outgoing edge summary is generated based on the dependent edges of the current graph shard pointing to other graph shards; the cross-shard incoming edge summary is generated based on the dependent edges of other graph shards pointing to the current graph shard; the interface signature summary is generated based on the interface signatures exported by the module within the current graph shard; the structural fingerprint is calculated based on the node set, edge set, cross-shard outgoing and incoming edge set, interface signature set, resource list summary, and construction artifact summary within the shard; and the version vector is used to represent the module version status corresponding to the current graph shard.

[0051] In one implementation, the boundary digest is generated through a hash operation; for example, the system normalizes and sorts the cross-shard outgoing edge set, cross-shard incoming edge set, exported interface signature set, version vector, structural fingerprint, and loading constraint set, and then calculates the boundary digest value.

[0052] Specifically, before generating the boundary summary, the system performs field normalization processing on the cross-shard outgoing edge set, cross-shard incoming edge set, exported interface signature set, version vector, and loading constraint set. The field normalization processing includes: sorting according to shard identifier, module identifier, interface name, interface version, and dependency type; uniformly representing version constraints as a preset version range; and encoding strong dependencies, weak dependencies, conditional dependencies, and lazy-loadable dependencies as preset dependency type values.

[0053] Subsequently, the system performs digest calculations on cross-shard outgoing edges, cross-shard incoming edges, interface signatures, structural fingerprints, and loading constraints, and combines these digests with the version vector to form the boundary digest. Using this boundary digest, the system can determine whether the boundary state of a remote shard matches the current graph view, even without loading the complete remote graph shards, based solely on the lightweight digest information. Figure 1 To.

[0054] S3 persists map fragments as baseline snapshots and incremental logs. In this step, the module runtime platform persists multiple map fragments as baseline snapshots and incremental logs.

[0055] A baseline snapshot is used to save the map fragments and their boundary summaries under a certain stable version. Each baseline snapshot includes a snapshot number, snapshot generation time, map version, map fragment list, fragment metadata of each map fragment, boundary summary of each map fragment, global version vector, and snapshot check value.

[0056] Incremental logs are used to record graph changes that have occurred since the baseline snapshot; incremental logs can be indexed by fragment identifier, entry module identifier, version vector, log sequence number, or transaction number.

[0057] Each incremental log record includes the log sequence number, transaction number, shard identifier, operation type, operation object type, operation object identifier, summary before change, summary after change, version vector, trigger source, dynamic dependency confidence, and operation timestamp.

[0058] For dependency edge additions, deletions, or attribute updates triggered by dynamic dependency confidence, the incremental log also records the dynamic dependency confidence, trigger window identifier, threshold determination result, and whether there are interface signature mismatches or version conflict events for the corresponding dynamic dependency edge. Before replaying the incremental log, the system determines whether the dynamic dependency edge can be applied to the current graph shard based on the summary before the change, version vector, and shard identifier. Only when the determination is successful will the corresponding update be performed in the current graph shard or shadow graph.

[0059] In one implementation, incremental logs within the same graph shard are arranged in ascending order of log sequence number; when the same graph change involves multiple graph shards, the corresponding incremental logs have the same transaction number and commit version vector; when the system replays the incremental logs, it first determines whether the pre-change summary in the incremental log is consistent with the current graph shard summary; if consistent, the incremental log is applied and a post-change summary is generated; if inconsistent, the replay of the incremental logs for that graph shard is stopped, and that graph shard is marked as requiring shadowing. Figure 1 Consistent updates. Each incremental log entry has an idempotent flag, ensuring that log entries that have already been replayed will not have their graph fragment states changed again when read.

[0060] The operation types include node addition, node deletion, node attribute update, dependency edge addition, dependency edge deletion, dependency edge attribute update, interface signature change, version constraint change, boundary summary change, and dynamic dependency confidence change.

[0061] When the build phase parse detects changes in module declarations, static imports, resource lists, or interface signatures, the system writes the corresponding changes to the incremental log. When the runtime probe detects missing dependency edges, dynamically imported dependencies, dependency loading via reflection, dependency loading via condition, or version conflict events, the system can also write the corresponding changes to the incremental log.

[0062] When reading the graph, the system does not need to re-parse all modules or load the complete bimorphic dependency graph. Instead, it reads the baseline snapshot corresponding to the target graph fragment and the necessary incremental log segments of the target graph fragment since the baseline snapshot according to the entry module request.

[0063] In a preferred embodiment, when the number of incremental logs for a certain graph segment exceeds a preset threshold, or when no interface conflict, version conflict, or boundary summary inconsistency event occurs in the graph segment within a preset stable window, the system merges the baseline snapshot and incremental logs of the graph segment into a new baseline snapshot; by merging snapshots, the log replay length during subsequent loading can be reduced.

[0064] S4, in response to the entry module loading request, loads the target graph fragments, necessary dependency closure fragments, and boundary summaries of unloaded fragments, and represents the unloaded fragments as ghost nodes. In this step, when the module runtime platform receives the entry module loading request, the system first determines the target map segment to which the entry module belongs.

[0065] Entry module loading requests can be triggered by user access, business processes, plugin startup, algorithm task startup, page route switching, service calls, or system initialization processes. Entry module loading requests include an entry module identifier, as well as the entry module version, runtime domain identifier, tenant identifier, loading environment parameters, and memory budget parameters.

[0066] The system searches for the target graph fragment containing the entry module in the graph fragment index based on the entry module identifier and entry module version. Then, the system reads the baseline snapshot of the target graph fragment and reads the necessary incremental log segments based on the version vector and log index of the target graph fragment.

[0067] The system merges the baseline snapshot of the target map fragment with the necessary incremental log segments to obtain the current state of the target map fragment.

[0068] Then, based on the dependency edges, cross-partition outgoing edge summaries, loading constraints, and version constraints in the target graph partitions, the system determines the necessary dependency closure partitions required for the current entry module to load.

[0069] Necessary dependency closure fragments refer to graph fragments that must be expanded during the loading process of the current entry module. For strong dependencies, critical path dependencies, API immediate call dependencies, version-constrained dependencies, or dependencies that do not allow lazy loading, the system determines their corresponding target fragments as necessary dependency closure fragments. For weak dependencies, conditional dependencies, and remote graph fragments that do not need to be expanded during the loading phase of the current entry module, the system does not read their complete node set and complete adjacency list, but only reads the boundary summary of the remote graph fragment and creates ghost nodes in the current graph view.

[0070] like Figure 3 As shown, a ghost node represents a remote graph shard that has not yet been loaded. The ghost node includes a remote shard identifier, remote shard version, remote shard boundary summary, remote shard version vector, interface constraints, loading constraints, whether it has been expanded, and an incremental log index. The ghost node is not a placeholder file for the executable module, nor is it an empty node used to directly replace the remote module. Instead, it is used to save the verifiable boundary state of the remote graph shard without reading the complete node set and adjacency list of the remote graph shard. The module runtime platform uses the ghost node to determine whether cross-shard dependencies satisfy the interface, version, structure, and loading constraints, and decides whether to expand the remote graph shard accordingly.

[0071] The expanded state includes not expanded, under verification, expanded, and verification failed. When a cross-shard dependency access hits a ghost node in the not expanded state, the system sets the ghost node to the under verification state and performs boundary digest verification based on the remote shard boundary digest, version vector, interface constraints, and loading constraints stored in the ghost node.

[0072] Once the verification passes and the baseline snapshot of the target graph fragment is read and the necessary incremental log replay is completed, the system replaces the ghost node with the complete node set and complete adjacency relationships of the target graph fragment, and sets its status to expanded. If the verification fails, the system sets the ghost node's status to verification failed and triggers a shadow node. Figure 1 Consistent updates.

[0073] Ghost nodes do not store the complete set of nodes and the complete adjacency list of the remote graph shard; thus, the current graph view can reduce memory usage while maintaining the verifiability of cross-shard dependencies.

[0074] After completing the above processing, the system generates a local graph view corresponding to the current entry module based on the loaded target graph fragments, necessary dependency closure fragments, and ghost nodes; this local graph view is used to drive the module loading process of the current entry module.

[0075] S5, in response to cross-shard dependency access, performs boundary summary verification on the target graph shard corresponding to the ghost node, and delays the expansion of the target graph shard when the verification passes. In this step, when a loaded module accesses a remote map fragment that has not yet been expanded during runtime, the system triggers cross-fragment dependency access processing.

[0076] Cross-shard dependency access can be generated by dynamic imports, reflection loading, conditional branch loading, runtime resource access, plugin invocation, event triggering, or data flow processes.

[0077] The system first identifies the source module, target module, or target interface that is accessed across shards, and then determines the ghost node corresponding to the target module or target interface.

[0078] Subsequently, the system reads the remote shard boundary summary, remote shard version vector, interface constraints, and loading constraints from the ghost node.

[0079] During boundary digest verification, the system queries the boundary index item corresponding to the ghost node based on the target module or target interface, and determines: whether the target interface matches the interface name, interface version, and interface parameters in the exported interface signature index; whether the source module version and the remote shard version vector satisfy the corresponding version constraints; whether the current cross-shard dependency edge is consistent with the dependency edge in the cross-shard outgoing edge index or cross-shard incoming edge index; whether the structural fingerprint recorded in the current graph view is consistent with the structural fingerprint in the remote shard boundary digest; and whether the current loading environment, memory budget, or network transmission budget meets the loading constraints of the remote shard. If all the above conditions are met, the boundary digest verification is determined to be successful; if any condition is not met, the boundary digest verification is determined to be unsuccessful.

[0080] If the boundary summary verification passes, the system reads the baseline snapshot of the target graph fragment and the corresponding necessary incremental log segments, and verifies whether the pre-change summary in the incremental log is consistent with the boundary summary recorded by the ghost node before replaying the incremental log. If they are consistent, the incremental log is replayed to obtain the current state of the target graph fragment, and the ghost node is replaced with the complete node set and complete adjacency relationship of the target graph fragment.

[0081] If the boundary summary verification fails, the system does not directly expand the target graph fragment, nor does it generate the current module loading list based on that target graph fragment. For the current cross-fragment dependency access request, if a previous stable baseline snapshot exists and its version constraints meet the current request, the system generates a downgraded loading result based on the previous stable baseline snapshot; if no previous stable baseline snapshot meets the conditions, the system returns the loading failure reason and aborts the current cross-fragment dependency loading. The system also writes the current cross-fragment dependency access event, verification failure type, source module identifier, target interface identifier, and current version vector to the incremental log and triggers the shadow... Figure 1 Consistent updates.

[0082] While performing cross-shard dependency access processing, the runtime probe continues to collect runtime dependency feedback, including the number of cross-shard accesses, target shard expansion time, module loading time, cache hit status, missing dependency edges, interface signature mismatch events, and version conflict events. This runtime dependency feedback is used to subsequently update the second dependency graph and further refine the bimorphic dependency graph.

[0083] In a preferred embodiment, when multiple loading requests simultaneously access the same unexpanded target graph fragment, the system creates a loading lease for that target graph fragment; the first triggering request initiates a fragment read operation, and subsequent requests for the same target graph fragment are attached to the same loading lease, without repeatedly reading the baseline snapshot or repeatedly replaying the incremental log; after the target graph fragment is expanded, the system provides the expansion result to the multiple requests attached to the loading lease; in this way, the overhead of repeated I / O and repeated log replay in high-concurrency scenarios can be reduced.

[0084] S6 responds to module version changes, hot module updates, or missing dependency edges during runtime by applying incremental logs to the shadow graph and performing consistency checks. If the checks pass, the current graph view is atomically replaced, and a module loading list and prefetching order are generated based on the replaced current graph view. like Figure 4 As shown, in this step, when there are changes in module version, hot module update, interface signature change, dependency edge change, boundary digest inconsistency, or runtime missing dependency edge, the system performs a two-phase consistency update.

[0085] The first stage is the shadow map update stage.

[0086] Instead of directly modifying the current graph view, the system creates a shadow graph based on the affected modules, affected dependency edges, affected graph fragments, and corresponding incremental logs.

[0087] The shadow graph is a temporary graph view that is independent of the current graph view; the module loading process in progress still reads the current graph view and does not read the shadow graph that has not yet been verified.

[0088] The system applies incremental logs to the shadow graph; the incremental logs include node additions, node deletions, node attribute updates, dependency edge additions, dependency edge deletions, dependency edge attribute updates, interface signature changes, version constraint changes, boundary summary changes, and dynamic dependency confidence changes.

[0089] When applying incremental logs in the shadow graph, the system only updates the affected modules, affected dependent edges, and affected graph fragments, without modifying the current graph view that is being loaded and read. For each incremental log, the system first verifies its transaction number, log sequence number, summary before change, and version vector. After the verification is successful, the system performs the corresponding node change, dependent edge change, interface signature change, or boundary summary change in the shadow graph, and recalculates the boundary summary and structural fingerprint of the affected graph fragment.

[0090] After incremental log application is completed, the system performs consistency checks on the shadow graph. These checks include: loop convergence verification, used to determine whether circular dependencies in the affected shards have been grouped into the same strongly connected component, or whether they have executable lazy loading constraints; interface compatibility verification, used to determine whether the target interface requested by the dependent source module matches the interface signature exported by the target module; version consistency verification, used to determine whether version constraints are satisfied between the dependent source module, the target module, and the graph shard version vectors; boundary digest consistency verification, used to determine whether the cross-shard inbound / outbound edge digests, interface signature digests, and structural fingerprints of the affected shards are consistent with the current shard state; and load constraint satisfiability verification, used to determine whether the current runtime environment, memory budget, network transmission budget, and cache state meet the module loading requirements.

[0091] If the shadow graph passes the consistency check described above, the system enters the second stage.

[0092] The second stage is the atomic substitution stage.

[0093] During the atomic replacement phase, the current graph view is read by the entry module loading request through the graph view reference; after the shadow graph passes the consistency check, the system switches the graph view reference from the old current graph view to the new current graph view corresponding to the shadow graph, and records the new graph version number; loading requests that have already obtained the old graph view reference before the switch continue to use the old current graph view to complete this loading; new loading requests initiated after the switch use the new current graph view; the old current graph view is released after no loading request references it.

[0094] When the shadow graph fails the consistency check, the system does not replace the current graph view, but instead rolls back to the previous stable baseline snapshot and records the reason for the failure. The reasons for the failure include inconsistent interface signatures, version constraint conflicts, inconsistent boundary summaries, circular dependencies that cannot converge, missing target modules, missing target resources, or insufficient confidence in dynamic dependencies.

[0095] After updating the current atlas view, the system generates a module loading list and prefetching order based on the current atlas view.

[0096] The module loading list indicates the set of modules required for loading the current entry module and the loading order; the prefetch order indicates which graph fragments or modules can be read or prefetched in advance, provided that the memory budget and network transmission budget are met.

[0097] When generating the module loading list and prefetch order, the system determines candidate graph shards based on dependency edges, version constraints, loading constraints, ghost node status, and dynamic dependency confidence in the current graph view. For candidate graph shards containing dynamic dependency edges, the system uses the dynamic dependency confidence as a technical parameter for the probability that the candidate graph shard will be actually accessed, and combines it with critical path length, historical module loading time, graph shard size, shard read time, module cache hit rate, graph shard cache hit rate, network throughput, memory budget, number of cross-shard edges, and current concurrent loading count to generate the module loading list and prefetch order.

[0098] In one implementation, the system segments the candidate map. Calculate prefetch score ,in, , A preset constant is used to prevent the denominator from being zero; The calculation is based on the size of the map fragment, the time taken to read the fragment, the network transmission volume, the estimated memory usage, and the loading lease conflict status. All of the above items are normalized to [0,1] before the calculation. The calculation is based on critical path contribution, historical hit rate, cross-shard access frequency, cache reuse probability, and dynamic dependency confidence. All of these factors are normalized to [0,1] before calculation. The system will then, provided that the current remaining memory budget and remaining network transmission budget meet the safety threshold, Candidate graph fragments with values ​​higher than the preset prefetch threshold are added to the prefetch queue, and the prefetch queue is submitted to the fragment reading thread pool, cache manager, and module loader for execution; prefetch graph fragments that are not actually accessed across fragments are released according to the cache eviction policy or reference count.

[0099] Therefore, this embodiment can complete entry module loading, cross-shard dependency access, dynamic dependency feedback, and module version consistency updates without fully loading the module dependency graph.

[0100] Example 2: Incremental Loading System for Module Dependency Graph This embodiment provides a module dependency graph incremental loading system; the system is used to execute the module dependency graph incremental loading method described in Embodiment 1.

[0101] like Figure 2 As shown, the system includes a dual-state graph generation module, a graph fragmentation summary module, a snapshot log management module, an entry incremental loading module, a delayed expansion feedback module, and a consistency update scheduling module.

[0102] 1. Dual-state map generation module The dual-state dependency graph generation module is used to obtain dependency information during the build phase and dependency feedback during the runtime phase, and then merge them to generate a dual-state dependency graph.

[0103] Specifically, the dual-state graph generation module parses the module declaration file, static import statements, resource list, configuration file, build script, interface definition file and build artifact summary to generate the first dependency graph.

[0104] The nodes in the first dependency graph include module identifier, module version, build artifact summary, and interface signature; the edges in the first dependency graph include dependency source module identifier, dependency target module identifier, dependency type, loading constraint, and version constraint.

[0105] The dual-state graph generation module also receives runtime dependency feedback; runtime dependency feedback is collected by the module loader probe, including dynamically imported dependencies, reflection-loaded dependencies, conditional-loaded dependencies, runtime resource access dependencies, actual loading time, cache hit status, missing dependency edges, interface signature mismatch events, version conflict events, and cross-shard access counts.

[0106] The bi-state graph generation module calculates the dynamic dependency confidence based on the number of times the dynamic dependency edge is triggered within the sliding time window, the most recent trigger time, the target module loading success rate, the number of trigger entry modules, the number of abnormal events, and the target module version failure flag. It then determines whether the dynamic dependency edge should be written to the incremental log or marked as a candidate deletion edge based on the addition or deletion threshold.

[0107] The dual-state dependency graph generation module generates a second dependency graph based on runtime dependency feedback, and merges the first dependency graph with the second dependency graph to obtain the dual-state dependency graph.

[0108] For dynamic dependency edges discovered during runtime, the bi-state graph generation module calculates the dynamic dependency confidence score. When the dynamic dependency confidence score reaches a preset threshold, the bi-state graph generation module outputs the dynamic dependency edge to the snapshot log management module for writing into the incremental log.

[0109] 2. Atlas Segmentation and Summarization Module The graph fragmentation and summarization module is used to fragment a bistate dependency graph and generate a boundary summary for each graph fragment.

[0110] Specifically, the graph sharding summary module divides the bimorphic dependency graph into multiple graph shards according to strongly connected components, entry modules, routing domains, business domains, version vectors, build artifact groups, tenant identifiers, and deployment regions.

[0111] In a preferred embodiment, the graph segmentation summary module first classifies module nodes with cyclic or close dependencies into the same candidate segment based on strongly connected components, and then merges or splits the candidate segments by combining the entry module and the segment size threshold.

[0112] The graph sharding summary module generates a boundary summary for each graph shard. The boundary summary includes cross-shard outbound edge summary, cross-shard inbound edge summary, interface signature summary, structural fingerprint, and version vector. Preferably, the boundary summary also includes a load constraint summary, a resource constraint summary, and a dynamic dependency confidence summary.

[0113] The graph fragment summary module outputs graph fragments and their boundary summaries to the snapshot log management module for persistence.

[0114] 3. Snapshot Log Management Module The snapshot log management module is used to persist graph fragments as baseline snapshots and incremental logs, and provide corresponding snapshot data and log data when the graph is loaded.

[0115] Specifically, the snapshot log management module saves the graph fragments, fragment metadata, and boundary summaries in a stable state as a baseline snapshot; the baseline snapshot includes the snapshot number, graph version, graph fragment list, boundary summary of each graph fragment, global version vector, and snapshot check value.

[0116] The snapshot log management module also records graph changes that occur after the baseline snapshot, forming an incremental log. The incremental log is used to record node additions, node deletions, node attribute updates, dependency edge additions, dependency edge deletions, dependency edge attribute updates, interface signature changes, version constraint changes, boundary summary changes, and dynamic dependency confidence changes.

[0117] When the ingress incremental loading module requests to load the graph data corresponding to a certain ingress module, the snapshot log management module returns the baseline snapshot of the target graph fragment and the necessary incremental log segments based on the ingress module identifier, graph fragment identifier and version vector.

[0118] When the number of incremental logs for a certain graph segment exceeds a preset threshold, or when no conflict occurs within a preset stable window, the snapshot log management module can merge the baseline snapshot and incremental logs of that graph segment into a new baseline snapshot.

[0119] 4. Incremental loading module for entry point The entry incremental loading module is used to respond to the entry module loading request, load the target graph fragments, necessary dependency closure fragments, and boundary summaries of unloaded fragments, and represent unloaded fragments as ghost nodes.

[0120] Specifically, after receiving the entry module loading request, the entry incremental loading module determines the target map fragment based on the entry module identifier and entry module version.

[0121] The entry incremental loading module requests the baseline snapshot and necessary incremental log segments of the target map fragment from the snapshot log management module, and replays the necessary incremental log segments to obtain the current state of the target map fragment.

[0122] The entry incremental loading module determines the necessary dependency closure fragments required by the current entry module based on the dependency edges, loading constraints, and version constraints in the target graph fragments, and loads the necessary dependency closure fragments.

[0123] For remote map fragments that do not need to be expanded during the current ingress module loading phase, the ingress incremental loading module only loads their boundary summaries and creates ghost nodes in the current map view.

[0124] Ghost nodes include remote shard identifier, remote shard version, remote shard boundary summary, remote shard version vector, interface constraints, load constraints, expansion status, and incremental log index; ghost nodes do not store the complete node set and complete adjacency list of the remote shard.

[0125] The ingress incremental loading module generates a local graph view based on the target graph fragments, necessary dependency closure fragments, and ghost nodes, and provides this local graph view to the consistency update scheduling module to generate the module loading list.

[0126] 5. Delayed Deployment Feedback Module The delayed unfolding feedback module is used to respond to cross-shard dependency access, perform boundary summary verification on the target graph shard corresponding to the ghost node, and delay unfolding the target graph shard when the verification passes, while collecting runtime dependency feedback.

[0127] Specifically, when a loaded module accesses a remote graph shard that has not yet been expanded, the delayed expansion feedback module determines the source module, target module, or target interface that is accessed across shards and finds the corresponding ghost node.

[0128] The delayed unpacking feedback module reads the boundary summary, version vector, interface constraints, and loading constraints from the ghost node and performs boundary summary verification.

[0129] The boundary summary verification includes interface signature verification, version vector verification, cross-shard dependency edge verification, structural fingerprint verification, and loading constraint verification.

[0130] When the boundary summary verification passes, the delayed expansion feedback module reads the baseline snapshot and necessary incremental log segments of the target graph fragment from the snapshot log management module, replays the necessary incremental log segments to obtain the current state of the target graph fragment, and replaces the ghost nodes with the complete node set and complete adjacency relationship of the target graph fragment.

[0131] When the boundary summary verification fails, the delayed unfolding feedback module sends this cross-shard dependency access event as runtime dependency feedback to the bi-state graph generation module and writes the corresponding changes into the incremental log so that the consistent update scheduling module can reconstruct the affected graph shards in the shadow graph.

[0132] In concurrent scenarios, the delayed unfolding feedback module can create loading leases for the same target graph shard, enabling multiple concurrent cross-shard access requests to share the same shard read operation and the same incremental log replay operation.

[0133] 6. Consistent Update Scheduling Module The consistency update scheduling module is used to respond to module version changes, hot module updates, or missing dependency edges during runtime. It applies incremental logs to the shadow graph and performs consistency checks. After the checks pass, it atomically replaces the current graph view and generates a module loading list and prefetching order based on the replaced current graph view.

[0134] Specifically, when the bi-state graph generation module or the delayed expansion feedback module outputs events such as module version change, module hot update, interface signature change, dependency edge change, boundary summary inconsistency, or missing dependency edge, the consistency update scheduling module determines the affected module, affected dependency edge, and affected graph fragment.

[0135] The consistency update scheduling module creates a shadow graph based on the baseline snapshot and incremental log of the affected graph shards, and applies the corresponding incremental log to the shadow graph.

[0136] Subsequently, the consistency update scheduling module performs consistency verification on the shadow graph; the consistency verification includes loop convergence verification, interface compatibility verification, version consistency verification, boundary summary consistency verification, and load constraint satisfiability verification.

[0137] If the shadow graph passes the consistency check, the consistency update scheduling module will atomically replace the shadow graph with the new current graph view. During the replacement process, loading requests that are currently using the old current graph view will continue to use the old current graph view to complete the current loading, while newly initiated loading requests will use the new current graph view.

[0138] If the shadow graph fails the consistency check, the consistency update scheduling module does not replace the current graph view, but rolls back to the previous stable baseline snapshot and records the reason for the check failure.

[0139] The consistent update scheduling module also generates a module loading list and prefetch order based on the current graph view. When generating the module loading list and prefetch order, the consistent update scheduling module uses parameters such as critical path length, historical module loading time, graph shard size, shard read time, module cache hit rate, graph shard cache hit rate, network throughput, memory budget, number of cross-shard edges, dynamic dependency confidence, and current concurrent loading quantity.

[0140] In a preferred embodiment, the consistent update scheduling module calculates a prefetch score based on the loading cost and loading benefit of candidate graph fragments. The loading cost is determined based on the graph fragment size, fragment reading time, network transmission volume, memory usage, and loading lease conflict status. The loading benefit is determined based on critical path contribution, historical hit rate, cross-fragment access frequency, cache reuse probability, and dynamic dependency confidence. Under the premise of satisfying the remaining memory budget and remaining network transmission budget, the consistent update scheduling module adds candidate graph fragments whose prefetch scores meet preset conditions to the prefetch queue and outputs the prefetch queue to the fragment reading thread pool, cache manager, and module loader.

[0141] Dynamic dependency confidence and prefetch score are both internal control parameters of the module loader, graph shard reading thread pool and cache manager. They are used to control dynamic dependency edge writing, graph shard expansion and prefetch queue generation, and are not used to recommend, evaluate, classify or make decisions about natural persons, user groups, transaction objects or content.

[0142] Example 3: The following uses a large-scale plug-in business platform as an example to illustrate the application process of this invention.

[0143] The platform includes multiple entry modules, such as page entry module, business process entry module, and plugin entry module; it also includes public library module, resource module, algorithm module, event handling module, and data processing module; there are static import dependencies, runtime dynamic import dependencies, resource access dependencies, and version constraint dependencies between different modules.

[0144] During the build phase, the system parses the module declaration files, static import statements, resource lists, and export interface signatures of each module to generate the first dependency graph.

[0145] During runtime, the module loader probe collects data on dynamic imports, reflection loading, conditional loading, resource access, actual loading time, cache hit status, and missing dependency edges, generating a second dependency graph.

[0146] The system merges the first dependency graph and the second dependency graph to obtain a bi-state dependency graph. Subsequently, the system segments the bi-state dependency graph according to strongly connected components and entry modules, and generates a boundary summary for each graph segment.

[0147] When a user accesses an entry module, the system only loads the target graph fragment to which the entry module belongs, as well as the necessary dependent closure fragments; for remote graph fragments that are not needed for the time being, the system only loads their boundary summaries and creates ghost nodes in the current graph view.

[0148] When cross-shard dependency access occurs during operation, the system first determines whether the target graph shard meets the current interface and version constraints based on the boundary summary and version vector in the ghost node. If it does, the system reads the baseline snapshot and necessary incremental log segments of the target graph shard and expands the ghost node into a complete graph shard. If it does not meet the constraints, the system reconstructs the affected shard in the shadow graph and atomically replaces the current graph view after the consistency check passes.

[0149] When a module undergoes a hot update, the system writes the interface signature changes, version constraint changes, and dependency edge changes to the incremental log. Instead of directly modifying the current graph view, the system applies the incremental log to the shadow graph and performs loop closure, interface compatibility, version consistency, and boundary digest consistency checks. If the checks pass, the system atomically replaces the shadow graph with the new current graph view. If the checks fail, it rolls back to the previous stable baseline snapshot.

[0150] If the verification fails due to inconsistent interface signatures or version constraint conflicts, the system retains the old current graph view and records the conflicting modules; if the verification fails due to inconsistent boundary summaries, the system rereads the baseline snapshot and necessary incremental log segments of the corresponding graph fragment and recalculates the structural fingerprint in the shadow graph.

[0151] Throughout the process, the system generates a module loading list and prefetching order based on the current graph view, historical module loading time, shard size, cache hit rate, network transmission volume, memory budget, and number of cross-shard edges. This reduces the amount of graph reading during cold starts, reduces memory usage, reduces redundant I / O, and improves consistency in hot module updates and multi-version operation scenarios.

[0152] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for incremental loading of module dependency graphs, characterized in that, Includes the following steps: Obtain dependency information during the build phase and dependency feedback during the runtime phase, generate a first dependency graph and a second dependency graph, and fuse them to obtain a bi-state dependency graph; The bistate dependency graph is segmented to obtain multiple graph segments. A boundary summary is generated for each graph segment, and the graph segments and the boundary summaries are saved as a baseline snapshot and an incremental log. Receive an entry module loading request, which includes an entry module identifier and an entry module version; determine the target map fragment based on the entry module identifier and the entry module version; read the baseline snapshot and necessary incremental log segments of the target map fragment; and replay the necessary incremental log segments to obtain the current state of the target map fragment. Based on the dependency edges, loading constraints, and version constraints in the current state, necessary dependency closure fragments are loaded, and boundary summaries are read for remote graph fragments that are not yet expanded during the current entry module loading phase. Ghost nodes are created to form the current graph view. In response to cross-shard dependency access, the system performs verification based on the boundary summary, version vector, interface constraints, and loading constraints stored in the ghost node. If the verification passes, it reads the baseline snapshot and necessary incremental log segments of the remote graph shard and replaces the ghost node with the remote graph shard. Create a shadow graph, apply incremental logs to the shadow graph and perform consistency checks. After the checks pass, replace the graph view with the new current graph view corresponding to the shadow graph, and generate a module loading list based on the new current graph view.

2. The incremental loading method for module dependency graphs according to claim 1, characterized in that, The build-time dependency information is obtained by parsing module declaration files, static import statements, resource lists, configuration files, build scripts, interface definition files, or build artifact summaries; the runtime dependency feedback is collected by the module loader probe during the module parsing, module instantiation, module import, module execution, resource access, cache reading, or loading exception handling stages.

3. The module dependency graph incremental loading method according to claim 1, characterized in that, Generating the second dependency graph includes: determining the actual module dependencies that occur during runtime based on runtime dependency feedback; marking dependency edges that do not exist in the first dependency graph as dynamic dependency edges or missing dependency edges; and writing the corresponding dependency edges into the incremental log or marking them as candidate deletion edges based on the dynamic dependency confidence.

4. The module dependency graph incremental loading method according to claim 1, characterized in that, When partitioning the bi-state dependency graph, first perform strong connected component analysis on the bi-state dependency graph to divide the module nodes with cyclic dependencies into the same candidate partition. Then, combine the entry module, version vector and partition size threshold to merge or split the candidate partitions.

5. The method for incremental loading of module dependency graphs according to claim 1, characterized in that, The boundary summary includes at least the cross-shard outgoing edge summary, cross-shard incoming edge summary, interface signature summary, structural fingerprint, load constraint summary, and version vector; when generating the boundary summary, the cross-shard outgoing edge set, cross-shard incoming edge set, exported interface signature set, version vector, and load constraint set are normalized.

6. The method for incremental loading of module dependency graphs according to claim 1, characterized in that, When replaying the necessary incremental log segment, it is determined whether the pre-change summary in the incremental log to be replayed is consistent with the current fragment summary recalculated from the node set, edge set, and boundary summary of the current graph fragment; if consistent, the incremental log is applied and a post-change summary is generated. If there is a discrepancy, playback will stop and the corresponding map segment will be marked as requiring shadow map consistency updates.

7. The method for incremental loading of module dependency graphs according to claim 1, characterized in that, When loading the necessary dependency closure fragments, the target fragments corresponding to strong dependencies, critical path dependencies, immediately invoked interface dependencies, version-constrained dependencies, or dependencies that do not allow lazy loading are identified as necessary dependency closure fragments; weak dependencies, conditional dependencies, or remote graph fragments that do not need to be expanded during the current entry module loading phase are represented as ghost nodes.

8. The method for incremental loading of module dependency graphs according to claim 1, characterized in that, The ghost node includes a remote shard identifier, a remote shard version, a remote shard boundary summary, a remote shard version vector, interface constraints, loading constraints, expansion status, and an incremental log index.

9. The method for incremental loading of module dependency graphs according to claim 1, characterized in that, The consistency verification includes loop convergence verification, interface compatibility verification, version consistency verification, boundary summary consistency verification, and load constraint satisfiability verification. If the verification passes, load requests that have already obtained a reference to the old current graph view will continue to use the old current graph view, and new load requests will use the new current graph view. If the verification fails, the current graph view will not be replaced.

10. A module dependency graph incremental loading system, characterized in that, include: The dual-state dependency graph generation module is used to obtain dependency information during the build phase and dependency feedback during the runtime phase, generate a first dependency graph and a second dependency graph, and fuse them to obtain a dual-state dependency graph. The graph segmentation and summarization module is used to segment bi-state dependency graphs and generate boundary summaries of the graph segments; The snapshot log management module is used to persist graph fragments as baseline snapshots and incremental logs, and provides the baseline snapshot and necessary incremental log segments for the target graph fragment; The entry incremental loading module is used to respond to the entry module loading request, load the target graph fragment, necessary dependency closure fragments, and boundary summaries of unloaded remote graph fragments, and create ghost nodes to form the current graph view; The delayed unfolding feedback module is used to respond to cross-shard dependency access, perform boundary summary verification on the remote graph shard corresponding to the ghost node, and unfold the remote graph shard when the verification passes. The consistency update scheduling module is used to atomically replace the current graph view after the shadow graph passes the consistency check, and generate a module loading list.

Images