Method and system for asynchronous execution of JavaScript at server side

Abstract

The invention discloses a method and a system for asynchronous execution of JavaScript at a server side, and relates to the technical field of computer software, the method comprises the following steps: constructing a multi-language runtime context pool on the server side based on GraalVM, and pre-compiling a script and a core class; when the script is loaded, asynchronous execution strategy parameters are injected into the corresponding isolation context; calculating the fragmentation number of the overall task submitted by the script, and carrying out overall task fragmentation; mapping the fragments to the corresponding isolation assembly lines according to the fragment execution categories, constructing feature vectors according to the fragments in the isolation assembly lines, calculating fragment priorities, and executing in sequence; after fragment execution is completed, execution time delay is collected, historical time delay prediction is updated, and when conditions are met, isolation retry is carried out, and compensation fragments are generated. Through pre-compilation, asynchronous execution strategy, adaptive fragmentation and priority scheduling, and compensation fragmentation generation, fault self-recovery and service continuity guarantee with low time delay response, high scheduling flexibility and controllability and automation are realized.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, specifically to a method and system for asynchronous execution of JavaScript on the server side. Background Technology

[0002] Traditional server-side JavaScript execution primarily relies on single-language runtimes such as Node.js, whose asynchronous mechanisms often employ Promises, async / await, or Web Workers. However, both event-loop-based Promises and async / await perform asynchronous scheduling within a single-threaded model. When faced with cross-language calls or a large number of concurrent requests, their execution efficiency and scalability are limited due to main thread blocking, frequent context switching, or excessively long callback chains. While Web Workers can achieve multi-threaded parallelism, thread management and data synchronization costs are high in high-concurrency, multi-script scenarios, making it difficult to meet the needs of cross-language interoperability and complex task orchestration. Although the GraalVM multi-language runtime supports Java and JavaScript interoperability, it lacks a systematic solution for asynchronous task sharding, strategy injection, and isolated execution, making it difficult to achieve efficient and controllable asynchronous execution in large-scale concurrent environments. Therefore, it is necessary to propose a new server-side JavaScript asynchronous execution method to improve cross-language asynchronous scheduling efficiency, reduce resource contention, and enhance fault self-healing capabilities. Summary of the Invention

[0003] Based on the shortcomings of the prior art described above, the purpose of this invention is to provide a method and system for asynchronous execution of JavaScript on the server side, so as to solve the above-mentioned technical problems.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a method for asynchronous execution of JavaScript on the server side, comprising: S1: On the server side, a multi-language runtime context pool is built based on GraalVM to pre-compile scripts and core classes; S2: When the script is loaded, the asynchronous execution strategy parameters are injected into the corresponding isolation context. The asynchronous execution strategy parameters include asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold and slice execution category. S3: Calculate the number of fragments for the overall task submitted by the script based on the overall task volume, historical latency prediction, concurrency elasticity parameters, asynchronous coupling degree and pre-compilation gain, and then perform overall task fragmentation; S4: Map the shards to the corresponding isolated pipelines according to the shard execution category. Construct feature vectors based on the asynchronous coupling degree, number of shards, number of historical failures, and aggregation coefficient of the shards within the isolated pipelines. Calculate the shard priority and execute them sequentially according to the shard priority. S5: After the sharding is completed, the execution latency is collected and the historical latency prediction is updated. When the sharding execution latency exceeds the preset threshold or the number of consecutive failures reaches the preset value, isolation retry is performed and a compensation shard is generated.

[0005] The present invention is further configured such that step S1 includes: The number of context instances is determined based on the number of concurrent requests, and the GraalVM multilingual context builder is called to initialize the instances; Set language interoperability permissions and runtime optimization options in each context instance to ensure consistency between Java and JavaScript environments; The JavaScript scripts to be executed are pre-compiled into an intermediate representation and the abstract syntax structure is cached by GraalVM. The core Java classes are partially pre-compiled by GraalVM local images and loaded into the context. The script initialization function and the Java class static initialization block are executed sequentially in the context instance to verify the correctness of pre-compiled resource loading and runtime. The context instance that passes the verification is then registered to the management queue.

[0006] The present invention is further configured such that step S2 includes: Read the asynchronous execution strategy parameter set and locate the corresponding isolation context instance based on the script's unique identifier; Convert the strategy parameter set into a multilingual interoperable format and set it as a global variable in the global namespace of the target isolation context; Perform policy parameter reading and validation within the isolation context to confirm that the parameter fields and ranges in the global variables meet the preset requirements.

[0007] The present invention is further configured such that step S3 includes: Obtain pre-compilation gain, asynchronous coupling degree, concurrency elasticity parameters, and historical latency prediction from the script submission request, and calculate the number of shards; The overall task data is divided into multiple fragments according to the number of fragments, and the data boundaries of each fragment are determined in turn. Generate fragment metadata for each fragment and send the fragment and fragment metadata to the subsequent execution scheduling module. The fragment metadata includes fragment identifier, data range and fragment parameters.

[0008] The present invention is further configured such that the calculation logic for the number of shards includes: The sharding baseline value is calculated based on the overall task volume, historical latency prediction, and concurrency elasticity parameters; Divide the fragmentation baseline value by the product of the asynchronous coupling margin and the pre-compiled gain to obtain the original number of fragments; Round the original number of shards up and trim it to the maximum concurrency limit to obtain the final number of shards.

[0009] The present invention is further configured such that step S4 includes: Identify the shard execution category and map the shard to the isolation pipeline that matches the execution category; Feature vectors are constructed based on the asynchronous coupling degree, number of fragments, historical failure count, and task aggregation coefficient of fragments within the isolated pipeline; Based on the feature vectors, a non-linear mapping is used to generate a segmentation and synthesis priority; The generated comprehensive priorities are sorted to form a priority queue, and fragments are dispatched to the corresponding isolated pipelines for execution in order of priority queue.

[0010] The present invention is further configured such that the asynchronous coupling degree is set as the first dimension of the feature vector, the reciprocal of the number of shards is set as the second dimension of the feature vector, the number of historical failures is set as the third dimension of the feature vector after exponential decay mapping, and the task aggregation coefficient is set as the fourth dimension of the feature vector after logarithmic smoothing mapping; and the four-dimensional feature vector is formed by combining the first to fourth dimensions in sequence.

[0011] The present invention is further configured such that step S5 includes: Receive feedback on the completion of fragment execution, and update the historical latency prediction of the fragment based on the execution latency; Determine whether the execution latency exceeds the preset maximum tolerable latency threshold or whether the number of consecutive failures of a shard reaches the preset failure threshold; The fragments that meet the timeout or failure criteria are marked as isolation retry targets and the isolation retry mechanism is triggered; Compensation fragments are generated based on the original fragment range and metadata information of the isolation retry target; Release the execution resources occupied by the original fragment and send the compensation fragment to the priority scheduling queue.

[0012] The present invention further specifies that the update logic for historical latency prediction is as follows: Receive feedback on the completion of fragment execution within the isolated pipeline and extract the actual execution latency of the fragment; Based on the preset memory decay coefficient, the original historical latency prediction of the shards and the extracted actual execution latency are fused in a weighted manner to obtain the updated historical latency prediction. Write the updated historical latency predictions to the shard's metadata store.

[0013] The present invention also provides a system for asynchronous execution of server-side JavaScript, for implementing the above-described method for asynchronous execution of server-side JavaScript, comprising: Pre-compilation module: On the server side, a multi-language runtime context pool is built based on GraalVM to pre-compile scripts and core classes; Parameter injection module: When the script is loaded, the asynchronous execution strategy parameters are injected into the corresponding isolation context. The asynchronous execution strategy parameters include asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold and slice execution category; Task sharding module: Calculates the number of shards for the overall task submitted by the script based on the overall task size, historical latency prediction, concurrency elasticity parameters, asynchronous coupling degree, and pre-compilation gain, and performs overall task sharding; The sharding mapping module maps shards to corresponding isolated pipelines based on their execution type. It constructs feature vectors based on the asynchronous coupling degree, number of shards, historical failure count, and aggregation coefficient of the shards within the isolated pipeline, calculates the shard priority, and executes them sequentially according to their priority. Update module: After the sharding is completed, the execution latency is collected and the historical latency prediction is updated. When the sharding execution latency exceeds the preset threshold or the number of consecutive failures reaches the preset value, isolation retry is performed and a compensation shard is generated.

[0014] This invention provides a method and system for asynchronous JavaScript execution on the server side. The method involves constructing a multi-language runtime context pool based on GraalVM on the server side to pre-compile scripts and core classes; injecting asynchronous execution strategy parameters into the corresponding isolation context during script loading, including asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold, and shard execution category; calculating the number of shards for the overall task submitted by the script based on the overall task volume, historical latency prediction, concurrency elasticity parameters, asynchronous coupling degree, and pre-compilation gain, and sharding the overall task; mapping shards to corresponding isolation pipelines according to their execution category; constructing feature vectors based on the asynchronous coupling degree, number of shards, historical failure count, and aggregation coefficient of the shards within the isolation pipelines; calculating shard priorities; and executing shards sequentially according to their priorities; collecting execution latency and updating historical latency predictions after shard execution; and performing isolation retries and generating compensated shards when shard execution latency exceeds a preset threshold or the number of consecutive failures reaches a preset value. The beneficial effects include: 1. By building a multi-language runtime context pool based on GraalVM on the server side and pre-compiling scripts and core classes, the initial execution startup latency can be significantly shortened and runtime compilation overhead can be reduced, providing low-latency response capabilities for high-concurrency request scenarios; 2. By injecting strategy parameters, including asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold and shard execution category, into the isolation context during the script loading phase, dynamic configuration and unified management of fine-grained scheduling strategies for each script can be achieved, improving the flexibility and controllability of asynchronous orchestration. 3. Based on pre-compilation gain, asynchronous coupling degree, concurrency elasticity parameters and historical latency prediction, adaptively calculate the number of shards and divide the overall task into multi-granularity subtasks to effectively balance single-shard execution efficiency and scheduling overhead, and enhance the scheduling stability of the system under different load conditions. 4. By mapping the execution category of the shards to independent isolated pipelines, and combining the coupling degree, shard granularity, historical failure count and aggregation coefficient to construct feature vectors for non-linear priority mapping, high-value or high-risk subtasks are executed first, thereby improving the overall throughput and resource utilization. 5. Real-time collection of shard execution latency and updating of historical predictions, as well as triggering isolation retries and compensation shard generation in case of timeouts or consecutive failures, to achieve rapid self-healing of abnormal shards and ensure business continuity, significantly reducing system failure rate and improving service reliability.

[0015] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating a method for asynchronous execution of JavaScript on a server side, as shown in an exemplary embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the structure of a server-side JavaScript asynchronous execution system, as shown in an exemplary embodiment of the present invention. Detailed Implementation

[0017] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0018] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0019] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0020] Example 1 A method for asynchronous execution of JavaScript on the server side, such as Figure 1 As shown, it includes: S1: On the server side, a multi-language runtime context pool is built based on GraalVM to pre-compile scripts and core classes; S2: When the script is loaded, the asynchronous execution strategy parameters are injected into the corresponding isolation context. The asynchronous execution strategy parameters include asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold and slice execution category. S3: Calculate the number of fragments for the overall task submitted by the script based on the overall task volume, historical latency prediction, concurrency elasticity parameters, asynchronous coupling degree and pre-compilation gain, and then perform overall task fragmentation; S4: Map the shards to the corresponding isolated pipelines according to the shard execution category. Construct feature vectors based on the asynchronous coupling degree, number of shards, number of historical failures, and aggregation coefficient of the shards within the isolated pipelines. Calculate the shard priority and execute them sequentially according to the shard priority. S5: After the sharding is completed, the execution latency is collected and the historical latency prediction is updated. When the sharding execution latency exceeds the preset threshold or the number of consecutive failures reaches the preset value, isolation retry is performed and a compensation shard is generated.

[0021] The present invention is further configured such that step S1 includes: The number of context instances is determined based on the concurrent request volume, and the GraalVM multi-language context builder is called to initialize the instances. Specifically, the concurrent request volume counted by the monitoring module is compared with the maximum concurrency value that a single instance can handle, and the required number of context instances is calculated by rounding up. The concurrent request volume refers to the total number of script instances to be executed per unit time, and the maximum concurrency value that a single instance can handle refers to the maximum number of concurrent script calls that a single GraalVM context can stably support under stress testing. In each context instance, language interoperability permissions and runtime optimization options are set to ensure consistency between Java and JavaScript environments. Specifically, the PolyglotContext constructor provided by GraalVM is called to enable both JavaScript and Java language engines for each instance, and language interoperability permissions are set to allow object passing and method calls between Java and JavaScript. At the same time, runtime optimization options (including inline caching and compilation level settings) are enabled in the constructor parameters to reduce the overhead of function calls and dynamic type checking, ensuring consistent performance in cross-language calling scenarios. The JavaScript scripts to be executed are pre-compiled into an intermediate representation and the abstract syntax tree is cached by GraalVM. Core Java classes are partially pre-compiled by GraalVM's native image and loaded into the context. Specifically, JavaScript script pre-compilation: GraalVM's Ahead-of-Time compilation technology converts the script source code into an intermediate representation (IR) and caches its abstract syntax tree (AST) to avoid re-performing lexical and syntactic analysis each time it is loaded. Core Java class pre-compilation: GraalVM's native image partial pre-compilation function is used to package key Java class static methods and field initialization values ​​into the native image to speed up class loading and static initialization. The intermediate representation refers to the intermediate data structure used by the compiler to optimize and generate native code, and the abstract syntax tree refers to the tree-like data structure that displays the hierarchical structure of the script syntax. The script initialization function and Java class static initialization block are executed sequentially in each context instance to verify the correctness of pre-compiled resource loading and runtime. Context instances that pass verification are registered to the management queue. Specifically, each context instance loads the pre-compiled script and core class sequentially, executes the initialization function within the script and the static initialization block of the Java class to trigger resource registration, global variable assignment, and class loading verification. This process verifies the integrity and runtime compatibility of pre-compiled resources, catches exceptions such as syntax errors and missing dependencies, and performs a success check on the execution results, including: no compilation errors, normal return of initialization functions, and no uncaught exceptions in static initialization. Verified context instances are added to the management queue in a first-in, first-out (FIFO) order and allocated to subsequent script execution requests by the scheduling module as needed. Instances that fail verification are destroyed and rebuilt to ensure that the context pool always maintains highly available and pre-compiled, usable instances.

[0022] When the server starts or a script is loaded for the first time, a multi-language context pool is dynamically configured based on the system's concurrency load. This ensures that high-concurrency requests can be met while avoiding excessive waste under resource constraints. Each instance in the context pool is a multi-language execution environment provided by GraalVM, supporting Java and JavaScript interoperability and eliminating runtime compilation overhead through pre-compilation technology.

[0023] The present invention is further configured such that step S2 includes: The asynchronous execution strategy parameter set is read, and the corresponding isolation context instance is located based on the script's unique identifier. Specifically, the strategy parameter set corresponding to the script is extracted from the script deployment package or centralized configuration storage, including asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold, and shard execution category. The script's unique identifier is a combination of script name, version number, and hash value, used to uniquely locate the script's isolation context instance in the context pool. In the multi-language runtime context pool manager, the corresponding PolyglotContext instance is retrieved based on the script's unique identifier. If the corresponding instance has not yet been allocated, an idle instance is popped from the pool and bound to the script. This involves creating an isolated context; an isolated context refers to an independent execution environment with its own global namespace and memory area, preventing conflicts between scripts regarding global variables. Furthermore, asynchronous coupling measures the degree of dependency between the currently submitted script task and other concurrent tasks, reflecting the degree of mutual constraints on shared data or global resources during task execution. The value range is (0,1), with values ​​closer to 1 indicating stronger dependencies and higher synchronization overhead; values ​​closer to 0 indicate high task independence and higher parallelism. The value selection logic is as follows: before script compilation, the number and frequency of statements accessing global variables, shared caches, and external services in the source code are analyzed. The basic coupling degree is calculated by counting and mapping the duration of blocking caused by resource locks, callback waits, or data synchronization during runtime. This percentage is then weighted and normalized with the static score to obtain the final coupling degree, which is set to 0.2 by default. The task aggregation coefficient describes the efficiency multiplication effect of batch merging of similar tasks compared to single task execution, reflecting the overall throughput improvement brought by batch processing. The value is greater than 1, with a larger value indicating a more significant batch merging effect. The calculation logic is as follows: the average execution latency of a single task and a batch of the same number of tasks are measured separately, and the ratio of the two is used as the initial aggregation coefficient, combined with the difference in CPU, memory, and other resource utilization during batch processing. The initial coefficients are adjusted according to empirical weights to obtain a comprehensive aggregation coefficient, which is set to 1.1 by default. The maximum tolerable latency threshold refers to the maximum expected execution latency allowed for a single sharded task under normal load conditions. Exceeding this latency is considered a timeout and triggers isolation and retry. The value range is a positive integer (in milliseconds or seconds). The specific value should be set in combination with business response requirements and system carrying capacity. The value logic is as follows: based on the maximum response time limit defined in the business service level agreement, the upper limit is set to this value; extract the 95% response percentile latency of similar sharded tasks from the monitoring data and multiply it by a safety factor (in a feasible embodiment of the present invention, the threshold is set to 1.2 or 1).5) The default value is 500 milliseconds; the shard execution category identifies the resource consumption type of the sharded task, used to dispatch the task to the most suitable execution thread pool or pipeline to avoid interference between different types of tasks. The value range is an enumeration, including compute-intensive and I / O-intensive. The value selection logic is as follows: during the loading or warm-up phase, analyze the proportion of arithmetic operations, memory accesses, and external call statements in the sharded code; during trial operation, sample CPU utilization and I / O wait time. If CPU utilization is consistently higher than I / O wait time, it is marked as compute-intensive; otherwise, it is marked as I / O-intensive. The strategy parameter set is converted into a multilingual interoperability format and set as a global variable, which is then mounted in the global namespace of the target isolation context. Specifically, the strategy parameter set is encapsulated into a multilingual interoperability object, including encapsulating the Java-side strategy as a PolyglotValue or a JSON string. The binding interface provided by GraalVM is called to write the encapsulated strategy object into the global namespace of the isolation context, such as creating and assigning a value to the __ASYNC_POLICY__ variable under the JavaScript global object. After completion, all strategy parameters can be accessed directly through the global variable within the script without additional cross-language calls. Within the isolation context, perform policy parameter reading and validation to confirm that the parameter fields and ranges in the global variables meet the preset requirements. Specifically, immediately execute a lightweight script fragment within the isolation context to read the __ASYNC_POLICY__ global variable and verify the type and value range of each field: the asynchronous coupling degree is a numerical value with a value range of (0,1); the task aggregation coefficient is a numerical value greater than or equal to 1; the maximum tolerable latency threshold is a positive integer; and the sharding execution category is a predefined enumeration value (including compute-intensive and I / O-intensive). If the validation fails, throw a context initialization exception and trigger instance reconstruction or script loading failure handling.

[0024] During the script loading phase, asynchronous execution strategy parameters are injected into the isolation context corresponding to each script in an interoperable manner to achieve dynamic and fine-grained control over the asynchronous scheduling behavior of each script. This process first obtains the complete set of strategy parameters from the script metadata or configuration center, then locates the isolation context instance based on the script's unique identifier, converts and binds the strategy parameters as global variables, and finally performs field and range validation within the context to ensure the parameters are accurate and usable.

[0025] The present invention is further configured such that step S3 includes: The system retrieves pre-compilation gain, asynchronous coupling degree, concurrency elasticity parameter, and historical latency prediction from the script submission request to calculate the number of shards. Specifically, it reads the injected pre-compilation gain from the script submission request payload, which reflects the efficiency improvement factor of the pre-compilation stage; reads the asynchronous coupling degree, which measures the resource dependency strength of the task with other concurrent tasks; reads the concurrency elasticity parameter, which characterizes the maximum concurrency the system can handle; and reads the historical latency prediction, which estimates the execution time of the current task based on the feedback from the previous round of execution. The sharding is determined based on these four parameters. The number of shards is calculated, balancing single-shard execution efficiency with concurrent scheduling overhead. The result is rounded up to ensure the number of shards is a positive integer. The pre-compilation gain is the efficiency increase at runtime compared to the non-pre-compiled mode after pre-compiling scripts and core classes on GraalVM. The calculation logic is as follows: first, the average startup latency and execution latency of the same script are measured separately in non-pre-compiled (interpreted) and pre-compiled modes; the ratio of non-pre-compiled latency to pre-compiled latency is used as the pre-compilation gain; then, the weighted average of multiple measurements is taken to eliminate the impact of occasional jitter. (Default value is not provided.) Set to 1.2; the asynchronous coupling degree has been explained in the aforementioned logic and will not be repeated here; the concurrency elasticity parameter is the maximum parallelism that the system can safely execute sharded tasks concurrently under the current hardware and thread pool configuration. It is used to balance the number of shards and the system resource carrying capacity. In the stress test environment, the concurrency is gradually increased, and the maximum concurrency is recorded when the CPU and memory usage do not exceed the preset threshold; multiply the maximum concurrency by a safety factor to ensure that there are still resource reserves in the production environment; at the same time, it can be automatically increased or decreased in conjunction with real-time monitoring to ensure system stability. The default setting is 4; the historical latency prediction is based on the actual execution latency of the previous one or more subtasks. The estimated execution latency of the next similar subtask is obtained through the prediction model and is used to guide the calculation of the number of shards and priorities. The value selection logic is as follows: when running for the first time, the initial prediction value can be the 95% response quantile latency of the previous version of the script or half of the business SLA; after each round of execution, the prediction value is updated by weighting the memory decay and the current observed latency; the prediction result is limited to an acceptable range (not lower than the shortest latency, but not higher than the maximum tolerance threshold) to avoid abnormal deviations. The base setting is 300 milliseconds; The overall task data is divided into multiple shards according to the number of shards, and the data boundaries of each shard are determined sequentially. Specifically, the dataset corresponding to the overall task is divided into N shards proportionally. When determining the data range of the i-th shard, the data index interval [start] is used. i end i The order is incremented sequentially to ensure no overlap or omission; Generate shard metadata for each shard and send the shard and shard metadata to the subsequent execution scheduling module. The shard metadata includes shard identifier, data range, and shard parameters. Specifically, generate a unique shard identifier for each shard to facilitate subsequent tracking and log association. Record the data range and four policy parameters corresponding to the shard in the metadata to form a self-contained task unit. After encapsulating the shard and metadata, send them to the execution scheduling module through a unified interface.

[0026] The present invention is further configured such that the calculation logic for the number of shards includes: The sharding baseline value is calculated based on the overall task volume, historical latency prediction, and concurrency elasticity parameters; Divide the fragmentation baseline value by the product of the asynchronous coupling margin and the pre-compiled gain to obtain the original number of fragments; The original number of shards is rounded up and then pruned to the maximum concurrency limit to obtain the final number of shards. Specifically, the final number of shards... , For the number of fragments, To round up, For the overall task size, For historical time delay prediction, For concurrent elasticity parameters, For asynchronous coupling, This represents the pre-compilation gain. The above calculation formula aims to adaptively determine the number of fragments based on the overall task size, execution latency estimation, system concurrency capabilities, and asynchronous task characteristics. To balance single-shard execution efficiency with concurrent scheduling overhead, the number of shards should be increased to shorten the execution time of each shard as the overall task size and estimated latency increase. Conversely, the number of shards can be appropriately reduced to lower scheduling and communication overhead as the system's concurrency capabilities and the performance gains from pre-compilation become more significant. The closer the dependencies between tasks (the higher the coupling), the fewer shards should be to avoid excessive partitioning leading to increased synchronization overhead. The final result is rounded to a positive integer to ensure the executability of the shard count. This calculation logic considers multiple influencing factors and can adaptively generate a reasonable number of shards under different task sizes, system loads, and dependency characteristics. This ensures single-shard execution efficiency while avoiding scheduling overhead and resource contention caused by excessive sharding, significantly improving the overall system concurrency throughput and stability.

[0027] The present invention is further configured such that step S4 includes: The execution category of each shard is identified, and the shards are mapped to isolated pipelines that match the execution category. Specifically, each shard is labeled as compute-intensive or I / O-intensive during the loading or warm-up phase. Based on this category, compute-intensive shards are dispatched to CPU-bound isolated thread pools, and I / O-intensive shards are dispatched to dedicated I / O thread pools. If a shard is not labeled with a category, it is dispatched to a general-purpose elastic thread pool. This mapping ensures that different types of shards run in different resource domains, preventing resource contention between them. A feature vector is constructed based on the asynchronous coupling degree, number of shards, number of historical failures, and task aggregation coefficient of shards within the isolated pipeline. Specifically, four parameters are extracted from the shard metadata: asynchronous coupling degree, number of shards, number of historical failures, and task aggregation coefficient. These parameters are then arranged in a fixed order to form a feature vector, which is used to compare the priority of shards within the same pipeline. This vector ensures that each dimension has a unique meaning and that the numerical range is controllable, facilitating subsequent mapping function processing. Based on the feature vector, a segmented comprehensive priority is generated through nonlinear mapping. Specifically, nonlinear mapping methods such as exponential, power, and logarithmic operations are used to map the feature vector to a single comprehensive priority value. Exponential operations are used to amplify the importance of highly coupled segments; power operations are used to smooth the influence of the number of segments; and logarithmic operations are used to weaken the extreme values ​​of the aggregation coefficient. This hybrid mapping takes into account the different influence patterns of each parameter on the priority, avoiding the deviation caused by simple linear weighting. The generated comprehensive priorities are sorted to form a priority queue, and the fragments are dispatched to the corresponding isolated pipelines for execution in sequence according to the priority queue order. Specifically, all fragments to be scheduled are sorted in descending order of the mapped priorities to form a priority queue. The scheduling module takes fragments from the head of the queue in sequence and dispatches them to the mapped isolated pipelines for execution. After execution, the feedback module feeds back the execution results and latency data to the priority mapping module to achieve closed-loop optimization. By using isolated resource mapping and nonlinear priority calculation based on multidimensional features in this step, the scheduling timeliness of critical fragments can be significantly improved, the mutual blocking caused by resource contention among different types of tasks can be reduced, and task reliability and batch processing efficiency can be taken into account, thereby improving the overall system throughput and stability.

[0028] The present invention is further configured such that the asynchronous coupling degree is set as the first dimension of the feature vector; the reciprocal of the number of fragments is set as the second dimension of the feature vector; the number of historical failures is set as the third dimension of the feature vector after exponential decay mapping; and the task aggregation coefficient is set as the fourth dimension of the feature vector after logarithmic smoothing mapping. The four-dimensional feature vector is formed by combining the first to fourth dimensions in that order. Specifically, the feature vector is represented as follows: , For the first The first isolation assembly line Feature vectors of each slice For the first The degree of asynchronous coupling of each partition. For the first The number of shards corresponding to each shard. For the first The number of historical failures corresponding to each shard. For the first The task aggregation coefficients corresponding to each slice; in the feature vector, the components for , indicating the first The asynchronous coupling degree of each partition is used to measure the strength of the resource dependency of that partition with other concurrent tasks; components for , For the first The total number of fragments in the overall task to which each fragment belongs, and the reciprocal of that number reflects the granularity of a single fragment: the more fragments there are (the finer the granularity). The smaller the value, the more differentiated the fine-grained fragments can be in the priority mapping; components for , For the first The historical failure count of each shard, exponentially mapped, can quickly reduce the priority of shards with high failure risk; components for , For the first The task aggregation coefficient of each shard, logarithmic mapping can smooth out extreme values ​​of high aggregation efficiency, while taking into account the overall efficiency improvement brought by batch processing; through the above feature vector design and nonlinear mapping, high-dependency, high-risk and high-efficiency shards can be accurately distinguished in the isolated pipeline, ensuring that key or low-risk shards are scheduled first, while suppressing shards that have failed multiple times from repeatedly occupying resources, thus achieving dual optimization of scheduling fairness and system throughput. The calculation logic for overall priority is as follows: , For the first The first isolation assembly line The overall priority of each fragment, , , and The dimension of the feature vector; specifically, the comprehensive priority calculation formula combines the four dimensions of the feature vector through different nonlinear mappings, taking into account the different impacts of coupling, granularity, failure risk, and batch benefits on scheduling priority: the exponential term amplifies the priority of highly coupled fragments, the exponentiation operation handles granularity differences, the logical function in the denominator suppresses high-risk fragment priority queuing, and the logarithmic term weakens extreme batch benefit values, ultimately generating a balanced comprehensive priority. Furthermore, Coupling components Through exponential mapping amplification, highly coupled fragments are given higher priority because they require more synchronization resources; Reciprocal component of fragment granularity Perform exponentiation to represent the effect of granularity on priority in a polynomial manner; Components of failure risk Apply logical mapping, when When the risk of failure is low, the denominator increases, thus reducing the overall priority. Components of batch benefits Logarithmic smoothing is applied to mitigate the impact of extreme values ​​of the aggregation coefficient on priority, ensuring a smooth growth of the priority function. Through this priority mapping logic, the execution order of different shards can be accurately distinguished within the same pipeline: it can prioritize the synchronization needs of highly coupled and large-granular shards, suppress excessive queuing of high-risk and low-reliability shards, and take into account the efficiency gains brought by batch processing, thereby maximizing system throughput and stability.

[0029] The present invention is further configured such that step S5 includes: The system receives feedback on the completion of a shard execution and updates the historical latency prediction of the shard based on the execution latency. Specifically, the scheduling module receives the feedback event when the shard execution ends and extracts the actual execution latency of the shard. Based on an autoregressive or weighted fusion model, the new latency is written into the shard metadata to update the historical latency prediction. The historical latency prediction always maintains a dynamic estimate of the execution latency of subsequent shards, which helps with adaptive sharding and priority scheduling. The system determines whether the execution latency exceeds a preset maximum tolerable latency threshold or whether the number of consecutive failures of a shard reaches a preset failure threshold. Specifically, it reads the maximum tolerable latency threshold from the shard metadata, which is 500ms in one feasible embodiment of the invention, and the consecutive failure count threshold, which is 3 times in another feasible embodiment of the invention. If the actual execution latency exceeds the threshold, or the number of consecutive failures of the shard increases to the threshold, it determines that the shard needs to be isolated and retried; otherwise, it clears the consecutive failure count and continues the next round of normal scheduling. The shards that meet the timeout or failure criteria are marked as isolation retry targets and the isolation retry mechanism is triggered. Specifically, for shards that are determined to be abnormal, they are marked as isolation retry targets and removed from the current pipeline scheduling queue. The shard and its execution context are placed in an isolation sandbox environment to avoid affecting the execution of other normal shards. The isolation environment can provide an independent thread pool and resource allocation to ensure that the retries of abnormal shards do not compete with the main pipeline resources. Compensation fragments are generated based on the original fragment range and metadata information of the isolation retry target. Specifically, new compensation fragments are generated by copying the original data range and metadata information of the isolation retry target. The compensation fragments inherit the fragment identifier, data range and policy parameters of the original fragments, and only a compensation mark is added. The compensation fragments are sent to the head of the priority scheduling queue so that the execution can be retried as soon as possible and the integrity of the service can be restored. The system releases the execution resources occupied by the original fragment and distributes the compensation fragment to the priority scheduling queue. Specifically, it reclaims the thread, context, and memory resources occupied by the isolated fragment in the original pipeline; it destroys or resets the fragment resources that failed in the isolation environment to ensure the health of the isolation pool; and it pushes the compensation fragment into the priority scheduling queue, waiting for the scheduler to dispatch it according to priority in the next cycle. Through real-time feedback and isolation compensation mechanisms, the system can quickly identify and isolate abnormal fragments, preventing the spread of faults; at the same time, by re-deploying the compensation fragment, it enables rapid recovery of business logic, significantly improving the robustness and availability of the system.

[0030] The present invention is further configured to: receive feedback on the completion of fragment execution within the isolated pipeline, extract the actual execution latency of the fragment; based on a preset memory decay coefficient, fuse the original historical latency prediction of the fragment and the extracted actual execution latency in a weighted manner to obtain an updated historical latency prediction; and write the updated historical latency prediction into the metadata storage of the fragment; specifically, the update logic of the historical latency prediction is as follows: , For the updated number Historical latency prediction for each segment For the first Historical latency prediction for each segment No. The first isolation assembly line The execution latency of each slice The memory decay coefficient, The latency amplification index is used to dynamically track and adaptively update the latency trend of shard execution by proportionally fusing the historical latency predictions of shards with the actual execution latency of the current execution and applying a nonlinear amplification to the current latency. The memory decay coefficient is used to balance the weights of historical information and new observations, while the latency amplification index is used to strengthen prediction corrections in the case of long-tail latency, retaining the previous round's... Historical latency prediction for each segment and with a proportionality coefficient Preserve its impact to ensure the predictive model's continuity with past steady states; reduce the execution delay for this operation. Upgrade to index In a feasible embodiment of the present invention, the value is 3 to highlight the risk of long latency scenarios, and is multiplied by a scaling factor. Introducing a prediction update, the sum of the two yields the updated historical latency prediction. This fusion method retains historically stable estimates while also being able to respond promptly to sudden long-term delay fluctuations, with a memory decay coefficient. The value range is (0.5, 0.9). Larger values ​​ensure stable estimation, while smaller values ​​enhance the response to sudden delays. The delay amplification index... The integer value of 3 is used to amplify the impact of fluctuations in long-latency scenarios. The above update logic combines historical memory and non-linear amplification mechanism, which can not only maintain smooth tracking of stable latency, but also capture and amplify sudden long-latency events in a timely manner, thereby making the sharding allocation and priority scheduling more accurate and improving the overall system's response reliability and anti-jitter capability.

[0031] This invention achieves low latency response, high scheduling flexibility and controllability, robust task throughput, and automated fault self-healing and business continuity assurance by constructing a multi-language context pool based on GraalVM, pre-compiling scripts and core classes, dynamically injecting asynchronous execution strategies, adaptively partitioning based on pre-compiled gains and system parameters, classifying and mapping to isolated pipelines and performing characteristic priority scheduling, and providing real-time feedback on retry and compensation partition generation.

[0032] Example 2 Please see Figure 2 This exemplary system for asynchronous server-side JavaScript execution, used to implement the aforementioned method for asynchronous server-side JavaScript execution, includes: Pre-compilation module: On the server side, a multi-language runtime context pool is built based on GraalVM to pre-compile scripts and core classes; Parameter injection module: When the script is loaded, the asynchronous execution strategy parameters are injected into the corresponding isolation context. The asynchronous execution strategy parameters include asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold and slice execution category; Task sharding module: Calculates the number of shards for the overall task submitted by the script based on the overall task size, historical latency prediction, concurrency elasticity parameters, asynchronous coupling degree, and pre-compilation gain, and performs overall task sharding; The sharding mapping module maps shards to corresponding isolated pipelines based on their execution type. It constructs feature vectors based on the asynchronous coupling degree, number of shards, historical failure count, and aggregation coefficient of the shards within the isolated pipeline, calculates the shard priority, and executes them sequentially according to their priority. Update module: After the sharding is completed, the execution latency is collected and the historical latency prediction is updated. When the sharding execution latency exceeds the preset threshold or the number of consecutive failures reaches the preset value, isolation retry is performed and a compensation shard is generated.

[0033] It should be noted that the server-side JavaScript asynchronous execution system provided in the above embodiments and the server-side JavaScript asynchronous execution method provided in the above embodiments belong to the same concept. The specific methods of execution of each module and unit have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the server-side JavaScript asynchronous execution system provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above, and this is not a limitation here.

[0034] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0035] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0036] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0037] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0038] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0039] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0040] In the several embodiments provided in this application, it should be understood that the disclosed system can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0041] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0042] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0043] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0044] 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 asynchronous execution of JavaScript on the server side, characterized in that, include: S1: On the server side, a multi-language runtime context pool is built based on GraalVM to pre-compile scripts and core classes; S2: When the script is loaded, the asynchronous execution strategy parameters are injected into the corresponding isolation context. The asynchronous execution strategy parameters include asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold and slice execution category. S3: Calculate the number of fragments for the overall task submitted by the script based on the overall task volume, historical latency prediction, concurrency elasticity parameters, asynchronous coupling degree and pre-compilation gain, and then perform overall task fragmentation; S4: Map the shards to the corresponding isolated pipelines according to the shard execution category. Construct feature vectors based on the asynchronous coupling degree, number of shards, number of historical failures, and aggregation coefficient of the shards within the isolated pipelines. Calculate the shard priority and execute them sequentially according to the shard priority. S5: After the sharding is completed, the execution latency is collected and the historical latency prediction is updated. When the sharding execution latency exceeds the preset threshold or the number of consecutive failures reaches the preset value, isolation retry is performed and a compensation shard is generated.

2. The method for asynchronous execution of JavaScript on the server side according to claim 1, characterized in that, Step S1 includes: The number of context instances is determined based on the number of concurrent requests, and the GraalVM multilingual context builder is called to initialize the instances; Set language interoperability permissions and runtime optimization options in each context instance to ensure consistency between Java and JavaScript environments; The JavaScript scripts to be executed are pre-compiled into an intermediate representation and the abstract syntax structure is cached by GraalVM. The core Java classes are partially pre-compiled by GraalVM local images and loaded into the context. The script initialization function and the Java class static initialization block are executed sequentially in the context instance to verify the correctness of pre-compiled resource loading and runtime. The context instance that passes the verification is then registered to the management queue.

3. The method for asynchronous execution of JavaScript on the server side according to claim 1, characterized in that, Step S2 includes: Read the asynchronous execution strategy parameter set and locate the corresponding isolation context instance based on the script's unique identifier; Convert the strategy parameter set into a multilingual interoperable format and set it as a global variable in the global namespace of the target isolation context; Perform policy parameter reading and validation within the isolation context to confirm that the parameter fields and ranges in the global variables meet the preset requirements.

4. The method for asynchronous execution of JavaScript on the server side according to claim 1, characterized in that, Step S3 includes: Obtain pre-compilation gain, asynchronous coupling degree, concurrency elasticity parameters, and historical latency prediction from the script submission request, and calculate the number of shards; The overall task data is divided into multiple fragments according to the number of fragments, and the data boundaries of each fragment are determined in turn. Generate fragment metadata for each fragment and send the fragment and fragment metadata to the subsequent execution scheduling module. The fragment metadata includes fragment identifier, data range and fragment parameters.

5. A method for asynchronous execution of JavaScript on the server side according to claim 4, characterized in that, The logic for calculating the number of fragments includes: The sharding baseline value is calculated based on the overall task volume, historical latency prediction, and concurrency elasticity parameters; Divide the fragmentation baseline value by the product of the asynchronous coupling margin and the pre-compiled gain to obtain the original number of fragments; Round the original number of shards up and trim it to the maximum concurrency limit to obtain the final number of shards.

6. A method for asynchronous execution of JavaScript on the server side according to claim 1, characterized in that, Step S4 includes: Identify the shard execution category of the shard and map the shard to the isolation pipeline that matches the execution category; Feature vectors are constructed based on the asynchronous coupling degree, number of fragments, historical failure count, and task aggregation coefficient of fragments within the isolated pipeline; Based on the feature vectors, a non-linear mapping is used to generate a segmentation and synthesis priority; The generated comprehensive priorities are sorted to form a priority queue, and fragments are dispatched to the corresponding isolated pipelines for execution in order of priority queue.

7. A method for asynchronous execution of JavaScript on the server side according to claim 6, characterized in that, The asynchronous coupling degree is set as the first dimension of the feature vector; the reciprocal of the number of fragments is set as the second dimension of the feature vector; the number of historical failures is set as the third dimension of the feature vector after exponential decay mapping; the task aggregation coefficient is set as the fourth dimension of the feature vector after logarithmic smoothing mapping; and the four-dimensional feature vector is formed by combining the first to fourth dimensions in order.

8. A method for asynchronous execution of JavaScript on the server side according to claim 1, characterized in that, Step S5 includes: Receive feedback on the completion of fragment execution, and update the historical latency prediction of the fragment based on the execution latency; Determine whether the execution latency exceeds the preset maximum tolerable latency threshold or whether the number of consecutive failures of a shard reaches the preset failure threshold; The fragments that meet the timeout or failure criteria are marked as isolation retry targets and the isolation retry mechanism is triggered; Compensation fragments are generated based on the original fragment range and metadata information of the isolation retry target; Release the execution resources occupied by the original fragment and send the compensation fragment to the priority scheduling queue.

9. A method for asynchronous execution of JavaScript on the server side according to claim 8, characterized in that, The update logic for historical latency prediction is as follows: Receive feedback on the completion of fragment execution within the isolated pipeline and extract the actual execution latency of the fragment; Based on the preset memory decay coefficient, the original historical latency prediction of the shards and the extracted actual execution latency are fused in a weighted manner to obtain the updated historical latency prediction. Write the updated historical latency predictions to the shard's metadata store.

10. A system for asynchronous execution of server-side JavaScript, used to implement the method for asynchronous execution of server-side JavaScript as described in any one of claims 1-9, characterized in that, include: Pre-compilation module: On the server side, a multi-language runtime context pool is built based on GraalVM to pre-compile scripts and core classes; Parameter injection module: When the script is loaded, the asynchronous execution strategy parameters are injected into the corresponding isolation context. The asynchronous execution strategy parameters include asynchronous coupling degree, task aggregation coefficient, maximum tolerable latency threshold and slice execution category; Task sharding module: Calculates the number of shards for the overall task submitted by the script based on the overall task size, historical latency prediction, concurrency elasticity parameters, asynchronous coupling degree, and pre-compilation gain, and performs overall task sharding; The sharding mapping module maps shards to corresponding isolated pipelines based on their execution type. It constructs feature vectors based on the asynchronous coupling degree, number of shards, historical failure count, and aggregation coefficient of the shards within the isolated pipeline, calculates the shard priority, and executes them sequentially according to their priority. Update module: After the sharding is completed, the execution latency is collected and the historical latency prediction is updated. When the sharding execution latency exceeds the preset threshold or the number of consecutive failures reaches the preset value, isolation retry is performed and a compensation shard is generated.

Images