A system and method for server-side javascript development debugging

Abstract

The application discloses a kind of server side Javascript development debugging systems and methods, it is related to computer software technical field, method includes: deployment GraalVM operating environment and configuration isolated sandbox, establish two-way communication channel;Difference coverage is calculated, and the hot difference injection or reload of script file is carried out;Based on multidimensional data, construct high-order tensor model, refine breakpoint candidate position, mapping registration to debugging engine;Real-time monitoring execution conflict and based on entropy increase rollback to stable snapshot;Verification repair patch candidate and implantation probe dynamically adjust breakpoint weight, calculate debugging comprehensive score, quantize debugging quality, greater than preset threshold, end debugging and disconnect debugging session, release resource.Secure and efficient update is realized by GraalVM sandbox and difference driven hot patch, with tensor breakpoint and entropy increase rollback guarantee debugging reliable, through the quality quantization of dynamic probe, realize automated, efficient server side JavaScript debugging.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software, in particular to a server-side Javascript development debugging system and method. BACKGROUND

[0002] With the wide application of cloud native architecture and microservices, JavaScript has not been limited to the front-end field, but has increasingly taken on server-side business logic. In the traditional Node.js environment, remote debugging usually relies on the V8 Inspector protocol to directly interface with the IDE, which has deficiencies in runtime isolation. The dependence on the production environment and the lack of effective protection for context isolation in the development and debugging process are not guaranteed.

[0003] The existing scheme usually uses the method of restarting the service or manually replacing the script when updating the code, which cannot dynamically inject patches without interrupting the existing execution context, thus prolonging the debugging period and affecting the availability of online services. Breakpoint setting often depends on the developer's experience and manual selection, ignoring the comprehensive analysis of historical debugging logs, source code complexity, and real-time performance indicators, so it is difficult to quickly locate high-value breakpoints, and the debugging accuracy and efficiency are limited.

[0004] In addition, when competition, conflict or uncaught exceptions occur during script execution, the traditional debugging environment usually requires manual intervention for restart or rollback, lacking real-time monitoring and automatic recovery capabilities for abnormal scenarios. In addition, performance monitoring and debugging processes are mutually exclusive, and cannot evaluate the performance impact in real time after patch injection or breakpoint adjustment, nor can they dynamically optimize breakpoint strategies based on runtime performance data. Based on the above deficiencies, there is an urgent need for a server-side JavaScript debugging method that can safely execute in an isolated sandbox, support hot differential injection, automatically refine breakpoints, self-healing rollback and intelligent patch generation, to comprehensively improve the efficiency, reliability and automation level of remote debugging. SUMMARY

[0005] Based on the above-mentioned shortcomings of the prior art, the present application aims to provide a server-side Javascript development debugging system and method to solve the above technical problems.

[0006] To achieve the above-mentioned purpose, the present application provides the following technical scheme: a server-side Javascript development debugging method, comprising:

[0007] S1: deploying a GraalVM runtime environment and configuring an isolated sandbox, and establishing a bidirectional communication channel with the isolated sandbox through WebSocket;

[0008] S2: Calculate the local and server difference coverage, perform script file hot difference injection or complete reload;

[0009] S3: Based on historical debugging logs, source code complexity and real-time performance probe data, build a high-order tensor model, refine breakpoint candidate positions, calculate breakpoint mapping accuracy and map to the debugging engine;

[0010] S4: Monitor the execution path conflict distribution and trigger self-healing rollback based on the entropy increase rate threshold to restore to the last stable snapshot and return to S2;

[0011] S5: Obtain a set of repair patch candidates, verify the repair patch candidates, calculate the patch efficiency, and apply the repair patch when the preset condition is met;

[0012] S6: Implant lightweight performance probes before and after the repair patch, collect latency and call frequency and adjust the breakpoint weight;

[0013] S7: Calculate the debugging comprehensive score based on the difference coverage, breakpoint mapping accuracy and patch efficiency, quantify the debugging quality, and end the debugging and disconnect the debugging session when the debugging quality is greater than the preset threshold.

[0014] The application further provides that step S1 comprises:

[0015] Deploy the GraalVM distribution package to the server file system predefined path, create an isolated sandbox instance, map the script project directory and the breakpoint directory;

[0016] Limit the sandbox process system call and network access through the security policy engine, and only open the WebSocket listening port;

[0017] Start the WebSocket server inside the sandbox, listen to the preset port and load the message distribution module;

[0018] After the debugging local initiates a WebSocket connection request, the server side verifies the identity certificate and returns the project structure summary, and after receiving the confirmation message, establishes a persistent communication channel with the sandbox.

[0019] The application further provides that step S2 comprises:

[0020] Divide the target script file into a plurality of data blocks according to a fixed length in the local workspace, and calculate the content digest respectively;

[0021] Request the data block digest list of the corresponding script file from the isolated sandbox through the established bidirectional communication channel;

[0022] Compare the local and server data block digests one by one to calculate the difference coverage;

[0023] When the difference coverage is greater than or equal to a preset threshold, extract the content of newly added or updated data blocks locally and dynamically load them into the runtime context through the GraalVM Polyglot API.

[0024] When the difference coverage falls below a preset threshold, terminate the current runtime instance, reload the complete script file, and start a new execution context.

[0025] The present invention is further configured such that the calculation logic for the difference coverage rate is as follows: , For differential coverage, This represents the number of local data blocks. The number of data blocks on the server. For the first The summary value of each local data block. For the first The digest value of a server data block. It is a very small positive number.

[0026] The present invention is further configured such that step S3 includes:

[0027] Collect historical debugging logs, source code complexity metrics, and runtime performance probe data to construct a third-order tensor model;

[0028] Perform high-order singular value decomposition on the third-order tensor model to obtain the code block index corresponding to the tensor dominant mode;

[0029] Map code block indices to source file line numbers and remove lines where breakpoints cannot be set.

[0030] The accuracy of the mapped line numbers and runtime bytecode offsets is verified, the breakpoint mapping accuracy is calculated, candidate breakpoints with values ​​higher than a preset threshold are retained, and the debugging engine interface is called to register candidate breakpoints in the runtime environment.

[0031] The present invention is further configured such that step S4 includes:

[0032] Conflict probes are implanted at the entry points of each execution branch and in key code segments to collect conflict events in real time;

[0033] The entropy increase rate is calculated based on the distribution of conflict events and compared with a preset threshold and a single-path conflict threshold.

[0034] When the entropy increase rate or the count of any path conflict exceeds a preset threshold, pause the current debugging instance and save the runtime context.

[0035] Restore to the last stable snapshot, including restoring script file state, patch injection points, and breakpoint registration information;

[0036] Rebuild the isolated sandbox execution context, reload the latest script snapshot and register breakpoints, return to step S2, and re-execute the difference coverage calculation and hot difference injection or full reload.

[0037] The present invention is further configured such that step S5 includes:

[0038] Construct a variable dependency graph based on the error stack information thrown at runtime and the dependencies between variables in the source code;

[0039] Obtain a set of patch candidates, perform functional verification on the patch candidates in an isolation sandbox, and compare the patch generation efficiency of the patch candidates with a preset threshold based on the verification results.

[0040] For patch candidates whose patch efficiency meets the preset conditions, inject them into the current runtime environment and replace the original code logic;

[0041] Patch candidates whose patch efficiency does not meet the preset conditions are marked for manual review.

[0042] The present invention is further configured such that step S6 includes:

[0043] Locate the corresponding source file line numbers before and after the patch based on the fixes applied to the runtime environment;

[0044] Ingress and exit probes are inserted at line numbers to record the time points and call events before and after patch execution;

[0045] At runtime, the initial timestamp is captured at the entry probe, and the termination timestamp is captured at the exit probe, accumulating the call count;

[0046] The timestamp difference and call count are periodically transmitted to the performance analysis module through the communication channel to update the corresponding breakpoint weights. The priority and triggering strategy of subsequent breakpoints are adjusted based on the updated weights.

[0047] The present invention is further configured such that step S7 includes:

[0048] Obtain the difference coverage, breakpoint mapping accuracy, and patch efficiency; calculate the overall debugging score; and compare it with the preset quality threshold.

[0049] When the overall score is greater than or equal to the preset quality threshold, a session termination command is sent to the debugging engine and the script execution is stopped.

[0050] The debugging end event is notified through the established communication channel, and the debugging interface is called to remove all breakpoints and close the debugging port;

[0051] Stop the performance probe sampling service and clear the buffered data; close the WebSocket communication channel and destroy the debug daemon in the isolation sandbox.

[0052] Archive or delete all temporary snapshots and patch files to restore the isolation sandbox to its initial state.

[0053] This invention also provides a system for server-side JavaScript development and debugging, used to implement the above-described method for server-side JavaScript development and debugging, the system comprising:

[0054] Environment Deployment Module: Deploys the GraalVM runtime environment and configures the isolation sandbox, establishing a bidirectional communication channel with the isolation sandbox via WebSocket;

[0055] First calculation module: Calculates the difference coverage between local and server, and performs hot difference injection or full reload of script files;

[0056] The second calculation module: Based on historical debugging logs, source code complexity and real-time performance probe data, it constructs a high-order tensor model, extracts candidate breakpoint positions, calculates breakpoint mapping accuracy, and registers the mapping to the debugging engine.

[0057] Conflict monitoring module: Monitors the conflict distribution in the execution path and triggers a self-healing rollback based on the entropy increase rate threshold, restoring to the last stable snapshot and returning to S2;

[0058] Patch generation module: Obtains a set of candidate patches, verifies the candidates, calculates patch efficiency, and applies the patch when preset conditions are met;

[0059] Weighting module: Implants lightweight performance probes before and after patching to collect latency and call frequency and adjust breakpoint weights;

[0060] Debugging Quantification Module: Calculates a comprehensive debugging score based on difference coverage, breakpoint mapping accuracy, and patch efficiency to quantify debugging quality. When the score exceeds a preset threshold, the debugging session ends, the debugging session is disconnected, and resources are released.

[0061] This invention provides a system and method for server-side JavaScript development and debugging. The method involves deploying a GraalVM runtime environment and configuring an isolation sandbox, establishing a bidirectional communication channel with the sandbox via WebSocket; calculating the difference coverage between the local and server environments, performing hot difference injection or full reloading of script files; constructing a high-order tensor model based on historical debugging logs, source code complexity, and real-time performance probe data, refining breakpoint candidate positions, calculating breakpoint mapping accuracy, and registering the mapping to the debugging engine; monitoring execution path conflict distribution and triggering a self-healing rollback based on an entropy increase rate threshold, restoring to the previous stable snapshot, and returning to S2; obtaining a set of repair patch candidates, verifying the patch candidates, calculating patch efficiency, and applying the repair patch when preset conditions are met; embedding lightweight performance probes before and after the repair patch, collecting latency and call frequency, and adjusting breakpoint weights; calculating a comprehensive debugging score based on difference coverage, breakpoint mapping accuracy, and patch efficiency to quantify debugging quality; and ending debugging and disconnecting the debugging session when the score exceeds a preset threshold, releasing resources. The beneficial effects include:

[0062] 1. Secure isolation and efficient hot update: Based on GraalVM sandbox environment and differential coverage-driven hot patch injection, scripts can be dynamically updated without restarting the running instance, which not only ensures debugging isolation security, but also significantly shortens patch verification and deployment time;

[0063] 2. Intelligent breakpoints and self-healing rollback: Breakpoints are automatically extracted through a high-order tensor model and the entropy increase of execution path conflicts is monitored in real time, which significantly improves the breakpoint hit rate and debugging accuracy; when anomalies are concentrated or conflicts are too high, the system automatically rolls back to a stable snapshot to maintain the continuity and reliability of the debugging environment.

[0064] 3. Automated Patch Generation and Quality Quantification: Verify patch candidates and combine dynamic probe feedback and geometric aggregation to achieve adaptive patch application and quantifiable debugging quality assessment, significantly improving debugging efficiency and result controllability.

[0065] 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

[0066] 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:

[0067] Figure 1 A flowchart illustrating a server-side JavaScript development and debugging method is shown as an exemplary embodiment of the present invention;

[0068] Figure 2 This is a schematic diagram illustrating the structure of a server-side JavaScript development and debugging system, as shown in an exemplary embodiment of the present invention. Detailed Implementation

[0069] 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.

[0070] 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.

[0071] 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.

[0072] Example 1

[0073] A method for server-side JavaScript development and debugging, such as Figure 1 As shown, it includes:

[0074] S1: Deploy the GraalVM runtime environment and configure the isolation sandbox, and establish a two-way communication channel with the isolation sandbox via WebSocket;

[0075] S2: Calculate the difference coverage between the local machine and the server, and perform hot difference injection or full reload of the script file;

[0076] S3: Based on historical debugging logs, source code complexity and real-time performance probe data, construct a high-order tensor model, extract candidate breakpoint positions, calculate breakpoint mapping accuracy, and register the mapping to the debugging engine.

[0077] S4: Monitor the distribution of execution path conflicts and trigger a self-healing rollback based on the entropy increase rate threshold to restore to the last stable snapshot, then return to S2;

[0078] S5: Obtain the set of patch candidates, verify the patch candidates, calculate the patch efficiency, and apply the patch when the preset conditions are met;

[0079] S6: Implant lightweight performance probes before and after the patch to collect latency and call frequency and adjust breakpoint weights;

[0080] S7: Calculates the overall debugging score based on difference coverage, breakpoint mapping accuracy, and patch efficiency to quantify debugging quality. When the score exceeds a preset threshold, the debugging session ends and resources are released.

[0081] The present invention is further configured such that step S1 includes:

[0082] Deploy the GraalVM distribution package to a predefined path in the server file system, create an isolated sandbox instance, and map the script project directory and patch directory. Specifically, unzip and install the GraalVM distribution package in the predefined path in the server file system, ensuring the integrity of its binary and library files; configure system environment variables so that entering the `js` command in any terminal or script can invoke the JavaScript runtime in GraalVM; restrict the permissions of this directory and its subdirectories to read and execute only by the debug user group through operating system permission management to prevent unauthorized processes or users from modifying runtime files; create an independent namespace using container technology or lightweight virtualization, which isolates the sandbox from the host system at the process, file system, and network levels; mount the script project directory and patch directory to the corresponding paths within the container in read-only or read-write mode, respectively, to ensure strict read-write boundaries between source code and test patches; apply system call whitelisting and network access control to processes within the sandbox through a security policy engine, allowing only necessary operations related to debugging;

[0083] The security policy engine restricts system calls and network access for the sandbox process, opening only the WebSocket listening port. A WebSocket server is started inside the sandbox, listening on a preset port and loading a message distribution module. Specifically, a WebSocket server is started inside the isolated sandbox, listening on a preset port; this server uses an asynchronous I / O framework to respond to multiple concurrent connections. A message distribution module is loaded, which dispatches instructions such as file fetching, file saving, and debugging startup to various function handlers based on the received JSON-RPC or custom message types. The WebSocket port is bound to the sandbox network interface, and firewall rules are set to allow only connections from debug client IPs or network segments.

[0084] After the debugger initiates a WebSocket connection request locally, the server verifies the identity credentials and returns a project structure summary. Upon receiving the confirmation message, it establishes a persistent communication channel with the sandbox. Specifically, the debug plugin initializes locally and initiates a WebSocket connection request to the server sandbox, carrying metadata such as identity credentials and the project root path in the connection message. After receiving the handshake request, the server verifies the identity credentials and, upon successful verification, returns a confirmation message containing the project directory structure and a list of file summaries. After receiving the confirmation message and verifying the consistency of the project structure, the client marks the WebSocket connection as ready, providing a reliable channel for subsequent file synchronization and debug command interaction.

[0085] The present invention is further configured such that step S2 includes:

[0086] In the local workspace, the target script file is divided into several data blocks of fixed length, and a content digest is calculated for each block. Specifically, the local target script is divided into multiple consecutive data blocks according to a preset byte or line length, and a content digest is calculated for each data block to obtain a unique identifier for the consecutive data blocks. This avoids the transmission of the entire file and facilitates efficient comparison and location of modified areas.

[0087] The system requests a list of data block digests for the corresponding script file from the isolation sandbox via the established bidirectional communication channel. Specifically, the system sends the script file path to the isolation sandbox via the established WebSocket channel. The sandbox reads the corresponding script, divides the data into blocks according to the same rules, calculates the digest, and returns the entire digest list to achieve consistency in digest format and block boundaries between the local and remote ends.

[0088] The local and server data block digests are compared one by one to calculate the difference coverage. Specifically, the local and remote digest lists are compared line by line, and the ratio of the number of data blocks that match exactly to the total number of blocks on the remote server is calculated to obtain the difference coverage. A high coverage indicates that most of the code has not been modified, and only the newly added or changed parts need to be injected into the runtime. A low coverage means that the overall differences in the script are too large, and it is not suitable for local updates.

[0089] The present invention is further configured such that the calculation logic for the difference coverage rate is as follows: , For differential coverage, This represents the number of local data blocks. The number of data blocks on the server. For the first The summary value of each local data block. For the first The digest value of a server data block. This is a very small positive number. Specifically, based on a data block-level digest difference metric, it quantifies the extent to which local modifications cover the remote script by calculating the ratio of the sum of the absolute differences between the local and server-side data block digests to the total sum of the server-side digests. A smaller ratio indicates fewer local changes and higher coverage; conversely, a full reload is required. The final difference coverage rate is obtained by subtracting this ratio from 1. , making The closer to 1, the higher the coverage; extremely small positive numbers The value range is 10 −6 Up to 10 −12 This is used to prevent division by zero errors when the sum of all server digests is zero, while having a negligible impact on the result. The above calculation logic can accurately determine which data blocks have been modified without restarting the entire runtime instance, and perform dynamic injection only on the modified parts, greatly reducing the context reconstruction overhead. At the same time, the full reload option is retained, and the system automatically switches to full reload when the modification is too large or the mismatch is too high, ensuring that the execution environment and script version are highly consistent, and realizing safe and efficient script updates and debugging.

[0090] When the difference coverage is greater than or equal to a preset threshold, the newly added or updated data block content is extracted locally and dynamically loaded into the runtime context via the GraalVM Polyglot API. Specifically, when the coverage reaches or exceeds the preset threshold, the content of all data blocks corresponding to digest mismatches is extracted locally, and these fragments are dynamically loaded into the current execution context via the GraalVM Polyglot API. The Polyglot API allows injecting new code fragments into the JavaScript engine in the sandbox without restarting the entire runtime and automatically updating function or variable definitions.

[0091] When the difference coverage is lower than a preset threshold, the current runtime instance is terminated, the complete script file is reloaded, and a new execution context is started. Specifically, if the coverage is lower than the threshold, the current runtime instance is first safely terminated, and all memory and resources are released. Then, the complete script file is reloaded in the isolation sandbox and a new execution context is started to ensure that the execution environment is completely consistent with the latest code, while restoring the previously registered breakpoints and debug state.

[0092] The present invention is further configured such that step S3 includes:

[0093] Historical debugging logs, source code complexity metrics, and runtime performance probe data are collected to construct a third-order tensor model. Specifically, in the script to be analyzed, which contains N code blocks, two types of features are extracted from each code block in the historical debugging logs: the number of exceptions and the number of calls, forming a matrix L (N rows, F1 = 2 columns). In the source code complexity, cyclomatic complexity is extracted, forming a vector C (N rows, F2 = 1 column). The runtime performance probe collects two samples at each function entry and exit: the average entry delay and the average exit delay, forming a matrix P (N rows, F3 = 2 columns). A third-order tensor X is constructed (first dimension is N, second dimension is F1+F2=3, third dimension is F3=2), and for each code block index... and the second-dimensional index and third-dimensional index ,definition: This means that log features or complexity metrics and performance data are in the same tensor along the probe dimension. Complete integration;

[0094] High-order singular value decomposition (HOSVD) is performed on the third-order tensor model to obtain the code block indices corresponding to the tensor dominant mode. Specifically, the tensor dimensions are defined to correspond sequentially to log feature entries, complexity dimensions, and probe sampling points. The three are aligned according to the same index, and tensor elements are filled to ensure that each code block cross-maps across the three data spaces. HOSVD is then performed on the constructed tensor to decompose it into a kernel tensor. With three factor matrices Sort by singular value size and select the top one. Pattern index corresponding to significant components ;

[0095] The code block index is mapped to the source file line number, and lines that cannot be set with breakpoints are removed. Specifically, the extracted code block index is mapped to the specific source file and line number range. The mapped line numbers are then subjected to syntax checks to remove comments, blank lines, and declaration lines that cannot be set with breakpoints, and the final candidate breakpoint positions are obtained.

[0096] The accuracy of the mapped line numbers and runtime bytecode offsets is verified, the breakpoint mapping accuracy is calculated, and candidate breakpoints with accuracy higher than a preset threshold are retained. The debugging engine interface is called to register candidate breakpoints in the runtime environment. Specifically, candidate line numbers are mapped to offsets in the GraalVM-compiled bytecode. The difference between the expected offset and the actual offset is compared, and the mapping accuracy is calculated. Registration is only performed on breakpoints with accuracy higher than the preset threshold to ensure that breakpoints are accurately hit at runtime. The GraalVM debugging interface is called to set breakpoints at each qualified breakpoint location in the runtime environment within the isolated sandbox. The registration results are fed back to the IDE plugin, the local breakpoint view is updated, and preparations are made to enter the debugging session.

[0097] The present invention is further configured such that step S4 includes:

[0098] Conflict probes are implanted at the entry points of each execution branch and key code segments to collect conflict events in real time. Specifically, probe code snippets are inserted at the entry point of each execution branch and key code segment to capture and record conflict or contention events at that location, including lock failure, resource contention, or exception throwing. When the probe is triggered at runtime, the conflict event is reported to the monitoring module in the form of a lightweight message, forming a conflict count vector for each branch for subsequent distribution analysis.

[0099] The entropy increase rate is calculated based on the distribution of conflict events and compared with a preset threshold and a single-path conflict threshold. Specifically, a probability distribution is constructed based on the conflict counts of each branch, and the conflict entropy increase rate is calculated to quantify the concentration of conflict events among each path. The entropy increase rate is compared with the preset entropy threshold, and the conflict count of each path is compared with the single-path threshold to determine whether to enter the self-healing process.

[0100] When the entropy increase rate or the number of any path conflicts exceeds a preset threshold, the current debugging instance is paused and the runtime context is saved. Specifically, when the entropy increase rate or the number of any path conflicts exceeds the corresponding threshold, the current debugging instance is immediately paused and the runtime context, including global variables, call stack and temporary state, is saved to memory or persistent cache.

[0101] Restore to the last stable snapshot, including restoring the script file state, patch injection points, and breakpoint registration information; specifically, restore the script file version, the position of injected patch fragments, and the current breakpoint registration information from the most recently saved stable snapshot; clear any residual state during runtime to ensure that the execution context is consistent with that at the time of the snapshot after restoration;

[0102] Rebuild the execution context of the isolated sandbox, reload the latest script snapshot and register breakpoints, return to step S2, and re-execute the difference coverage calculation and hot difference injection or full reload; specifically, reinitialize the execution environment in the isolated sandbox, load the restored script snapshot and re-register breakpoints, restore the original debugging session structure; reactivate the performance probe and debug communication channel to complete the context reconstruction; automatically jump to step S2, recalculate the local and server difference coverage, and perform hot difference injection or full reload according to the results to enter a new debugging iteration.

[0103] The present invention is further configured such that step S5 includes:

[0104] A variable dependency graph is constructed based on the error stack information thrown at runtime and the dependency relationships between variables in the source code. Specifically, the function name, line number and call chain of the exception are extracted from the error stack thrown at runtime. At the source code level, the variable definition and usage relationships in the functions or modules involved in the exception are analyzed, and a directed graph structure with variables as nodes and dependencies as edges is constructed to reflect the data flow and control dependencies.

[0105] A set of patch candidates is obtained, and their functionality is verified within an isolation sandbox. Based on the verification results, patch efficiency is calculated and compared with a preset threshold. Specifically, the patch candidates in the patch candidate set are applied sequentially to the runtime environment of the isolation sandbox, and regression tests are executed under existing test cases or predefined verification scripts. The verification process mainly checks whether the patch can eliminate the original anomaly and ensures that no new errors are introduced or normal logic is broken. Patch efficiency is calculated based on the repair effect and verification cost of each patch during the verification process. The patch efficiency is compared with a preset threshold to select patch candidates that are both efficient and safe. In a feasible embodiment of the present invention, the calculation logic of patch efficiency is as follows: , For patch efficiency, it is used to evaluate the overall performance of automatically generated patches. This serves as a patch candidate sequence number index, used to distinguish between multiple automatically synthesized fix patches. For the first The execution time saved by a patch in eliminating existing errors in an isolated verification environment, i.e., the difference in runtime of test cases or scripts before and after the patch was not applied. For the first The time spent on functional verification of a patch typically includes the total time consumed by executing the verification script or test cases.

[0106] For patch candidates whose patch efficiency meets preset conditions, they are injected into the current runtime environment; specifically, for candidate patches whose patch efficiency reaches or exceeds the threshold, they are automatically injected into the current runtime context through the Polyglot API, replacing the original code logic and taking effect immediately.

[0107] For patch candidates whose patch efficiency does not meet the preset conditions, they are marked for manual review; specifically, for patches that do not meet the efficiency standards, the patch code and verification report are retained and submitted to the developers for manual review and adjustment.

[0108] The present invention is further configured such that step S6 includes:

[0109] Locate the corresponding line numbers in the source file before and after the patch applied to the runtime environment; specifically, based on the applied patch information, obtain the line number range of the start and end of the patch in the source file; determine the line numbers corresponding to each key position before and after the patch to provide accurate positioning for probe insertion, including entry and exit points;

[0110] Entry and exit probes are inserted at line numbers using code instrumentation to record the time points and call events before and after patch execution. Specifically, an entry probe code snippet is inserted at the entry line number to record the initial timestamp and call context before patch execution; an exit probe code snippet is inserted at the exit line number to record the termination timestamp after patch execution and incrementally update the call count. Probe insertion is accomplished through modification of the Abstract Syntax Tree (AST) or the GraalVM Polyglot API, ensuring seamless integration with the original logic and extremely low overhead.

[0111] At runtime, the initial timestamp is captured at the entry probe, the termination timestamp is captured at the exit probe, and the call count is accumulated. Specifically, the initial timestamp and unique probe identifier are captured and temporarily stored locally at the entry probe; the termination timestamp is captured at the exit probe and the difference between the two is calculated to obtain the single delay, while the call count of that probe is accumulated. The above information is cached in memory or a lightweight message queue in the form of (unique probe identifier probeId, single delay Δt, accumulated call count count).

[0112] The timestamp difference and call count are periodically transmitted to the performance analysis module via the communication channel to update the corresponding breakpoint weights. Based on the updated weights, the priority and triggering strategy of subsequent breakpoints are adjusted. Specifically, buffered data packets are sent to the performance analysis module periodically or according to a fixed data volume threshold via the existing WebSocket channel. The analysis module maps each record to the corresponding breakpoint entry based on the probeId, calculates the new round of latency distribution and call frequency changes, and updates the breakpoint's weight value according to a predetermined algorithm. The predetermined algorithm includes a weight value gain algorithm based on latency increase and frequency increase, specifically including:

[0113] The average delay recorded by the probe during the last weight update. and call frequency As a baseline; the current average delay collected from the probe is denoted as . The current call frequency is recorded as The delay increase ratio is defined as: This is used to quantify the degree of performance degradation caused by patches or breakpoints; the frequency increase ratio is defined as... This is used to measure the change in execution heat of the code block at the breakpoint. It is a very small positive number, representing the ratio of delay increase. Applying nonlinear mapping functions This compresses the positive delay increase to the (0,1) range; and increases the frequency increase ratio. Applying the exponential mapping function , , To adjust the coefficients so that the faster the frequency increases, the closer the mapping value is to 1; define the total gain coefficient. ,in, , (0,1) are the adjustment coefficients for delay and frequency mapping, respectively, used to control their respective contributions to the weights. The new weight value is determined by the original weights. With gain coefficient Multiplying them together gives: The updated weights are immediately written back to the debug daemon or plugin to adjust the priority and triggering strategy of subsequent breakpoints.

[0114] The debugging daemon adjusts the priority and triggering strategy of subsequent breakpoints based on the updated weights. Specifically, the updated weight values ​​are sent to the debugging daemon or IDE plugin via RPC or event push. After receiving the updated weights, the daemon or plugin adjusts the priority sorting and triggering conditions of the subsequent breakpoint list, including skipping low-weight breakpoints or docking high-weight breakpoints in advance, thus optimizing the debugging flow.

[0115] The present invention is further configured such that step S7 includes:

[0116] The process involves obtaining difference coverage, breakpoint mapping accuracy, and patch efficiency, calculating a comprehensive debugging score, and comparing it with a preset quality threshold. Specifically, the final difference coverage is read from the thermal difference injection module; the average breakpoint mapping accuracy is obtained from the breakpoint registration module; the patch efficiency of applied patches is obtained; and the three indicators are mapped to a comprehensive score according to a predetermined geometric aggregation or other nonlinear combination strategy. No limitations are imposed on the geometric aggregation or other nonlinear combination strategies here; they can be flexibly set according to the application scenario. The comprehensive score is compared with the preset quality threshold to determine whether the current debugging quality meets the termination condition.

[0117] When the overall score is greater than or equal to the preset quality threshold, a session termination command is sent to the debugging engine and the script execution is stopped; specifically, when the overall score is not lower than the threshold, a session termination command is sent to the debugging engine in the sandbox, triggering the script execution interruption; after the debugging engine responds, it immediately stops all debugging threads to ensure that the script no longer executes;

[0118] The debug end event is notified through the established communication channel, and the debug interface is invoked to remove all breakpoints and close the debug port; specifically, all registered breakpoints are removed through the debug interface; the debug port is closed, and the connection with the GraalVM debug subprocess is disconnected.

[0119] Stop the performance probe sampling service and clear the buffered data; close the WebSocket communication channel and destroy the debug daemon in the isolation sandbox; specifically, stop the performance probe sampling service, clear the probe buffered data locally and in the sandbox; close the WebSocket communication channel and disconnect the bidirectional connection with the IDE plugin;

[0120] Archive or delete all temporary snapshots and patch files, and restore the isolated sandbox to its initial state; specifically, destroy the debug daemon, release the computing and memory resources of the sandbox instance; archive or delete temporary snapshots and patch files; reinitialize the sandbox file system, and restore it to the initial code version and blank patch directory.

[0121] By unifying and quantifying core indicators and automatically determining whether debugging has reached the predetermined quality, this invention can objectively and promptly end high-quality debugging sessions, avoiding the arbitrariness and errors of manual judgment. The full-process resource cleanup and sandbox recovery mechanism ensures that the debugging environment returns to its initial state after each session, providing a clean and controllable basic environment for subsequent debugging, thereby significantly improving the efficiency, security, and repeatability of remote debugging.

[0122] Example 2

[0123] Please see Figure 2 This exemplary system for server-side JavaScript development and debugging is used to implement the aforementioned method for server-side JavaScript development and debugging. The system includes:

[0124] Environment Deployment Module: Deploys the GraalVM runtime environment and configures the isolation sandbox, establishing a bidirectional communication channel with the isolation sandbox via WebSocket;

[0125] First calculation module: Calculates the difference coverage between local and server, and performs hot difference injection or full reload of script files;

[0126] The second calculation module: Based on historical debugging logs, source code complexity and real-time performance probe data, it constructs a high-order tensor model, extracts candidate breakpoint positions, calculates breakpoint mapping accuracy, and registers the mapping to the debugging engine.

[0127] Conflict monitoring module: Monitors the conflict distribution in the execution path and triggers a self-healing rollback based on the entropy increase rate threshold, restoring to the last stable snapshot and returning to S2;

[0128] Patch generation module: Obtains a set of candidate patches, verifies the candidates, calculates patch efficiency, and applies the patch when preset conditions are met;

[0129] Weighting module: Implants lightweight performance probes before and after patching to collect latency and call frequency and adjust breakpoint weights;

[0130] Debugging Quantification Module: Calculates a comprehensive debugging score based on difference coverage, breakpoint mapping accuracy, and patch efficiency to quantify debugging quality. When the score exceeds a preset threshold, the debugging session ends, the debugging session is disconnected, and resources are released.

[0131] It should be noted that the server-side JavaScript development and debugging system provided in the above embodiments and the server-side JavaScript development and debugging 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 development and debugging 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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 server-side JavaScript development and debugging, characterized in that, include: S1: Deploy the GraalVM runtime environment and configure the isolation sandbox, and establish a two-way communication channel with the isolation sandbox via WebSocket; S2: Calculate the difference coverage between the local machine and the server, and perform hot difference injection or full reload of the script file; S3: Based on historical debugging logs, source code complexity and real-time performance probe data, construct a high-order tensor model, extract candidate breakpoint positions, calculate breakpoint mapping accuracy, and register the mapping to the debugging engine. S4: Monitor the distribution of execution path conflicts and trigger a self-healing rollback based on the entropy increase rate threshold to restore to the last stable snapshot, then return to S2; S5: Obtain the set of patch candidates, verify the patch candidates, calculate the patch efficiency, and apply the patch when the preset conditions are met; S6: Implant lightweight performance probes before and after the patch to collect latency and call frequency and adjust breakpoint weights; S7: Calculates the overall debugging score based on difference coverage, breakpoint mapping accuracy, and patch efficiency to quantify debugging quality. When the score exceeds a preset threshold, the debugging session ends and resources are released.

2. The method for server-side JavaScript development and debugging according to claim 1, characterized in that, Step S1 includes: Deploy the GraalVM distribution package to a predefined path in the server file system, create an isolated sandbox instance, and map the script project directory and patch directory; The security policy engine restricts system calls and network access for sandbox processes, allowing only the WebSocket listening port to be open. Start a WebSocket server inside the sandbox, listen on a preset port and load the message dispatch module; After the debugger initiates a WebSocket connection request locally, the server verifies the identity credentials and returns a project structure summary. After receiving the confirmation message, it establishes a persistent communication channel with the sandbox.

3. The method for server-side JavaScript development and debugging according to claim 1, characterized in that, Step S2 includes: In the local workspace, the target script file is divided into several data blocks of fixed length, and the content summary is calculated for each block. Request a list of data block digests for the corresponding script file from the isolation sandbox through the established two-way communication channel; The local and server data block summaries are compared one by one, and the difference coverage is calculated. When the difference coverage is greater than or equal to a preset threshold, extract the content of newly added or updated data blocks locally and dynamically load them into the runtime context through the GraalVM Polyglot API. When the difference coverage falls below a preset threshold, terminate the current runtime instance, reload the complete script file, and start a new execution context.

4. The method for server-side JavaScript development and debugging according to claim 3, characterized in that, The calculation logic for the difference coverage rate is as follows: , For differential coverage, This represents the number of local data blocks. The number of data blocks on the server. For the first The summary value of each local data block. For the first The digest value of a server data block. It is a very small positive number.

5. The method for server-side JavaScript development and debugging according to claim 1, characterized in that, Step S3 includes: Collect historical debugging logs, source code complexity metrics, and runtime performance probe data to construct a third-order tensor model; Perform high-order singular value decomposition on the third-order tensor model to obtain the code block index corresponding to the tensor dominant mode; Map code block indices to source file line numbers and remove lines where breakpoints cannot be set. The accuracy of the mapped line numbers and runtime bytecode offsets is verified, the breakpoint mapping accuracy is calculated, candidate breakpoints with values ​​higher than a preset threshold are retained, and the debugging engine interface is called to register candidate breakpoints in the runtime environment.

6. The method for server-side JavaScript development and debugging according to claim 1, characterized in that, Step S4 includes: Conflict probes are implanted at the entry points of each execution branch and in key code segments to collect conflict events in real time; The entropy increase rate is calculated based on the distribution of conflict events and compared with a preset threshold and a single-path conflict threshold. When the entropy increase rate or the count of any path conflict exceeds a preset threshold, pause the current debugging instance and save the runtime context. Restore to the last stable snapshot, including restoring script file state, patch injection points, and breakpoint registration information; Rebuild the isolated sandbox execution context, reload the latest script snapshot and register breakpoints, return to step S2, and re-execute the difference coverage calculation and hot difference injection or full reload.

7. The method for server-side JavaScript development and debugging according to claim 1, characterized in that, Step S5 includes: Construct a variable dependency graph based on the error stack information thrown at runtime and the dependencies between variables in the source code; Obtain a set of patch candidates, perform functional verification on the patch candidates in an isolation sandbox, and compare the patch generation efficiency of the patch candidates with a preset threshold based on the verification results. For patch candidates whose patch efficiency meets preset conditions, inject them into the current runtime environment; Patch candidates whose patch efficiency does not meet the preset conditions are marked for manual review.

8. A method for server-side JavaScript development and debugging according to claim 1, characterized in that, Step S6 includes: Locate the corresponding source file line numbers before and after the patch based on the fixes applied to the runtime environment; Ingress and exit probes are inserted at line numbers to record the time points and call events before and after patch execution; At runtime, the initial timestamp is captured at the entry probe, and the termination timestamp is captured at the exit probe, accumulating the call count; The timestamp difference and call count are periodically transmitted to the performance analysis module through the communication channel to update the corresponding breakpoint weights. The priority and triggering strategy of subsequent breakpoints are adjusted based on the updated weights.

9. A method for server-side JavaScript development and debugging according to claim 1, characterized in that, Step S7 includes: Obtain the difference coverage, breakpoint mapping accuracy, and patch efficiency; calculate the overall debugging score; and compare it with the preset quality threshold. When the overall score is greater than or equal to the preset quality threshold, a session termination command is sent to the debugging engine and the script execution is stopped. The debugging end event is notified through the established communication channel, and the debugging interface is called to remove all breakpoints and close the debugging port; Stop the performance probe sampling service and clear the buffered data; close the WebSocket communication channel and destroy the debug daemon in the isolation sandbox. Archive or delete all temporary snapshots and patch files to restore the isolation sandbox to its initial state.

10. A system for server-side JavaScript development and debugging, used to implement the server-side JavaScript development and debugging method according to any one of claims 1-9, characterized in that, include: Environment Deployment Module: Deploys the GraalVM runtime environment and configures the isolation sandbox, establishing a bidirectional communication channel with the isolation sandbox via WebSocket; First calculation module: Calculates the difference coverage between local and server, and performs hot difference injection or full reload of script files; The second calculation module: Based on historical debugging logs, source code complexity and real-time performance probe data, it constructs a high-order tensor model, extracts candidate breakpoint positions, calculates breakpoint mapping accuracy, and registers the mapping to the debugging engine. Conflict monitoring module: Monitors the conflict distribution in the execution path and triggers a self-healing rollback based on the entropy increase rate threshold, restoring to the last stable snapshot and returning to S2; Patch generation module: Obtains a set of candidate patches, verifies the candidates, calculates patch efficiency, and applies the patch when preset conditions are met; Weighting module: Implants lightweight performance probes before and after patching to collect latency and call frequency and adjust breakpoint weights; Debugging Quantification Module: Calculates a comprehensive debugging score based on difference coverage, breakpoint mapping accuracy, and patch efficiency to quantify debugging quality. When the score exceeds a preset threshold, the debugging session ends, the debugging session is disconnected, and resources are released.

Images