US-12625687-B1 - Parallel execution component initialization using static dependency analysis

US12625687B1US 12625687 B1US12625687 B1US 12625687B1US-12625687-B1

Abstract

Techniques for parallel execution component initialization using static dependency analysis are disclosed. In an example method, a computing device receives a set of program code comprising execution components. The computing device generates a dependency graph based on a static analysis and determines a subset of the execution components that do not depend on any other execution component of the execution components. The computing device configures an initialization thread pool to initialize in parallel a plurality of the subset of the execution components. Responsive to a first execution component of the subset of the execution components completing initialization, the computing device determines a second execution component that depends on the first execution component and does not depend on any other uninitialized execution components of the execution components or any of the subset of the execution components initializing. The computing device configures the thread pool to initialize the second execution component.

Inventors

Zhuo Li
Xiaohuan Pan
Jingjin Xie

Assignees

Zoom Video Communications, Inc.

Dates

Publication Date: 20260512
Application Date: 20230927

Claims (20)

1 . A method, comprising: receiving a set of program code comprising one or more execution components; generating a dependency graph of the execution components based on a static analysis of the set of program code; determining, from the dependency graph, a first subset of the one or more execution components that do not depend on any other execution component of the one or more execution components; configuring an initialization thread pool to initialize in parallel a plurality of the first subset of the one or more execution components; responsive to a first execution component of the first subset of the one or more execution components completing initialization, determining, from the dependency graph, a second execution component that: depends on the first execution component; and does not depend on: any other uninitialized execution components of the one or more execution components; or any of the first subset of the one or more execution components initializing; and configuring the initialization thread pool to initialize the second execution component.
2 . The method of claim 1 , wherein the dependency graph is a directed acyclic graph.
3 . The method of claim 1 , wherein the dependency graph includes one or more dependencies among the one or more execution components, wherein a dependency comprises: an element defined in a provider execution component; and an interface to the element used in a dependent execution component.
4 . The method of claim 1 , further comprising receiving an indication from a build automation tool to parallelize initialization of the one or more execution components.
5 . The method of claim 4 , wherein the indication from the build automation tool to parallelize the initialization is generated by a build automation tool plugin.
6 . The method of claim 1 , further comprising: receiving an indication to start an application comprising a second subset of the one or more execution components; responsive to the indication to start the application, generating the initialization thread pool based on the configured initialization thread pool; and initializing the second subset of the one or more execution components in parallel.
7 . The method of claim 6 , wherein the application includes one or more components of a video conferencing platform.
8 . The method of claim 6 , further comprising restarting the application comprising the second subset of the one or more execution components using the configured initialization thread pool.
9 . The method of claim 6 , further comprising receiving one or more modifications to the configured initialization thread pool, wherein the generated initialization thread pool is based on the modified configured initialization thread pool.
10 . The method of claim 6 , wherein the application is based on an application development framework, comprising a plugin for parallelizing execution component initialization.
11 . A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: receiving a set of program code comprising one or more execution components; generating a dependency graph of the execution components based on a static analysis of the set of program code; determining, from the dependency graph, a first subset of the one or more execution components that do not depend on any other execution component of the one or more execution components; determining an execution component initialization order to initialize in parallel a plurality of the first subset of the one or more execution components; for each execution component of the plurality of the first subset of the one or more execution components, based on the execution component initialization order: generating a first thread; and initializing an execution component; responsive to a first execution component of the first subset of the one or more execution components completing initialization, determining, from the dependency graph, a second execution component that: depends on the first execution component; and does not depend on: any other uninitialized execution components of the one or more execution components; or any of the first subset of the one or more execution components initializing; creating a new thread; and initializing the second execution component.
12 . The non-transitory computer-readable medium of claim 11 , wherein the dependency graph is a directed acyclic graph.
13 . The non-transitory computer-readable medium of claim 11 , further comprising receiving an indication from a build automation tool to parallelize initialization of the one or more execution components, wherein the indication from the build automation tool to parallelize the initialization is generated by a build automation tool plugin.
14 . The non-transitory computer-readable medium of claim 11 , further comprising the operations: starting an application comprising a second subset of the one or more execution components, wherein: the application includes one or more components of a video conferencing platform; and the application is based on an application development framework, comprising a plugin for parallelizing execution component initialization.
15 . The non-transitory computer-readable medium of claim 11 , further comprising the operations: receiving one or more modifications to the execution component initialization order; and for each execution component of the plurality of the first subset of the one or more execution components, based on the modified execution component initialization order: generating a second thread; and initializing an execution component.
16 . A system comprising: one or more processors; and one or more computer-readable storage media storing instructions which, when executed by the one or more processors, cause the one or more processors to perform operations including: receiving a set of program code comprising one or more execution components; generating a dependency graph of the execution components based on a static analysis of the set of program code; determining, from the dependency graph, a first subset of the one or more execution components that do not depend on any other execution component of the one or more execution components; generating an executor service configured to initialize in parallel a plurality of the first subset of the one or more execution components; for each execution component of the plurality of the first subset of the one or more execution components: submitting the execution component to the executor service for initialization on a first new thread; and receiving a callback corresponding to the initialization of the execution component; responsive to a first execution of a callback corresponding to the initialization of a first execution component of the first subset of the one or more execution components, determining, from the dependency graph, a second execution component that: depends on the first execution component; and does not depend on: any other uninitialized execution components of the one or more execution components; or any of the first subset of the one or more execution components initializing; submitting the second execution component to the executor service for initialization on a second new thread; receiving a callback corresponding to the initialization of the second execution component; and detecting a second execution of the callback corresponding to the initialization of the second execution component.
17 . The system of claim 16 , wherein the dependency graph is a directed acyclic graph.
18 . The system of claim 16 , further comprising receiving an indication from a build automation tool to parallelize initialization of the one or more execution components, wherein the indication from the build automation tool to parallelize the initialization is generated by a build automation tool plugin.
19 . The system of claim 16 , further comprising the operations: starting an application comprising a second subset of the one or more execution components, wherein: the application includes one or more components of a video conferencing platform; and the application is based on an application development framework, comprising a plugin for parallelizing execution component initialization.
20 . The system of claim 16 , further comprising receiving one or more modifications to the generated executor service, wherein the executor service is reconfigured and restarted based on the modifications to the generated executor service.

Description

FIELD The present application generally relates to software engineering, and more particularly relates to parallel execution component initialization using static dependency analysis. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate one or more certain examples and, together with the description of the example, serve to explain the principles and implementations of the certain examples. FIG. 1 shows an example system that provides videoconferencing functionality to various client devices. FIG. 2 shows an example system in which a video conference provider provides videoconferencing functionality to various client devices. FIG. 3 shows an example of a system for parallel component initialization using static dependency analysis, according to some aspects of the present disclosure. FIG. 4 is an illustration of a dependency graph that may be used during parallel component initialization using static dependency analysis, according to some aspects of the present disclosure. FIG. 5 is an illustration of an example application lifecycle used in some systems for parallel component initialization using static dependency analysis, according to some aspects of the present disclosure. FIG. 6 shows a flowchart of an example method implementing parallel component initialization using static dependency analysis, according to some aspects of the present disclosure. FIG. 7 shows an example computing device suitable for use in example systems or methods for parallel component initialization using static dependency analysis according to this disclosure. DETAILED DESCRIPTION Examples are described herein in the context of techniques for parallel execution component initialization using static dependency analysis. Those of ordinary skill in the art will realize that the following description is illustrative only and is not intended to be in any way limiting. Reference will now be made in detail to implementations of examples as illustrated in the accompanying drawings. The same reference indicators will be used throughout the drawings and the following description to refer to the same or like items. In the interest of clarity, not all of the routine features of the examples described herein are shown and described. It will, of course, be appreciated that in the development of any such actual implementation, numerous implementation-specific decisions must be made in order to achieve the developer's specific goals, such as compliance with application- and business-related constraints, and that these specific goals will vary from one implementation to another and from one developer to another. Video conferencing continues to both supplement and complement personal and enterprise communications with increasing frequency and importance. Indeed, it is by now a routine part of communicating with others for most people, both in the home and the workplace. One reason for the proliferation of remote video communications is the reliability of the platforms provided by some video conferencing platforms. A cornerstone of reliability for modern, complex cloud-based computing systems is fast recovery from inevitable system faults. For example, a typical deployment scenario involves modular, containerized software, with numerous instances of various components running, scaling vertically and horizontally according to demand. Some frequency of system faults is inevitable due to network failures, undetected program bugs, disk and memory space limits, and so on. Operational planning must assume that software modules will need to be restarted from time to time. Thus, in production, the time for a particular software module to start up is of particular importance when planning for fault or disaster recovery. Likewise, during development, long startup times may cause bottlenecks during development and testing cycles. Nevertheless, in some cases, software startup and initialization can take an undesirably long amount of time. Consider the typical example of an application framework (e.g., Spring, Django, Ruby on Rails, Express.js, etc.) that provides application programming interfaces (APIs) for rapid software development of web applications. Typically, developers need only author execution components (e.g., JavaBeans, Spring beans, etc.) that encapsulate business logic and can otherwise rely on modules provided by the application framework for common, repetitive tasks, middleware, or low-level interfaces. Upon startup of the application framework, the execution components may be automatically started and initialized by the application framework. In some existing systems, the execution components may be initialized and started serially (e.g., one at a time according to a particular ordering). Serial initialization and startup of execution components may result in needlessly long startup times, particularly when hardware or virtualized resources for paralle