System and method for developing and debugging Javascript at server side

Abstract

The invention discloses a system and method for developing and debugging Javascript at a server side, and relates to the technical field of computer software, and the method comprises the following steps: deploying a GraalVM operating environment, configuring an isolation sandbox, and establishing a two-way communication channel; calculating a difference coverage rate, and performing thermal difference injection or reloading of the script file; constructing a high-order tensor model based on the multi-dimensional data, extracting breakpoint candidate positions, and mapping and registering the breakpoint candidate positions to a debugging engine; monitoring an execution conflict in real time and rolling back to a stable snapshot based on entropy increase; verifying the repair patch candidates, implanting a probe to dynamically adjust the breakpoint weight, calculating a debugging comprehensive score, quantifying the debugging quality, and when the debugging comprehensive score is greater than a preset threshold value, ending debugging, disconnecting a debugging session and releasing resources. Safe and efficient updating is achieved through a GraalVM sandbox and a difference drive hot patch, reliable debugging is guaranteed through tensor breakpoints and entropy increase rollback, and automatic and efficient server side JavaScript debugging is achieved through quality quantification of a dynamic probe.

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 experience of developers to choose manually, 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 purpose of the present application is to provide a server-side Javascript development debugging system and method to solve the above technical problems.

[0006] To achieve the above purpose, the present application provides the following technical scheme: a server-side Javascript development debugging method, comprising: S1: deploying a GraalVM runtime environment and configuring an isolated sandbox, and establishing a bidirectional communication channel with the isolated sandbox through WebSocket; S2: calculating the difference coverage between the local and the server, and performing hot differential injection or complete reloading of the script file; 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; 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; S5: Obtain a repair patch candidate set, verify the repair patch candidate, calculate the patch efficiency, and apply the repair patch when the preset condition is met; S6: Implant a lightweight performance probe before and after the repair patch, collect the delay and call frequency and adjust the breakpoint weight; 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.

[0007] The application further provides that step S1 comprises: Deploy the GraalVM release package to the server file system predefined path, create an isolated sandbox instance, map the script project directory and breakpoint directory; Limit the sandbox process system call and network access through the security policy engine, and only open the WebSocket listening port; Start the WebSocket server inside the sandbox, listen to the preset port and load the message distribution module; After the local debugging initiates the WebSocket connection request, the server checks the identity certificate and returns the project structure summary, and establishes a persistent communication channel with the sandbox after receiving the confirmation message.

[0008] The application further provides that step S2 comprises: 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; Request the data block digest list of the corresponding script file from the isolated sandbox through the established bidirectional communication channel; Compare the local and server data block digests one by one, and calculate the difference coverage; When the difference coverage is greater than or equal to the preset threshold, extract the newly added or updated data block content locally, and dynamically load it to the runtime context through the GraalVM Polyglot API; When the difference coverage is less than the preset threshold, terminate the current runtime instance, reload the complete script file and start a new execution context.

[0009] The application further provides that the calculation logic of the difference coverage is: , The difference coverage is, the number of local data blocks, the number of server data blocks, the digest value of the mth local data block, the digest value of the nth local data block, the digest value of the mth server data block, the digest value of the nth server data block, a very small positive number.

[0010] The application further provides that step S3 comprises: collecting historical debugging logs, source code complexity indicators and runtime performance probe data to build a three-order tensor model; performing high-order singular value decomposition on the three-order tensor model to obtain code block indexes corresponding to tensor dominant modes; mapping the code block indexes to source file line numbers and eliminating lines that cannot be set breakpoints; performing precision verification on the mapped line numbers and runtime bytecode offsets, calculating breakpoint mapping precision, retaining candidate breakpoints higher than a preset threshold, and calling a debugging engine interface to register the candidate breakpoints in a runtime environment.

[0011] The application further provides that step S4 comprises: implanting conflict probes at each execution branch entrance and key code segment to collect conflict events in real time; calculating an entropy increase rate based on conflict event distribution and comparing it with a preset threshold and a single-path conflict threshold; when the entropy increase rate or any path conflict count exceeds the preset threshold, suspending the current debugging instance and saving the runtime context; restoring to the last stable snapshot, including restoring script file state, patch injection points and breakpoint registration information; rebuilding an isolated sandbox execution context, reloading the latest script snapshot and registering breakpoints, and returning to step S2 to re-execute difference coverage calculation and hot difference injection or complete reloading.

[0012] The application further provides that step S5 comprises: constructing a variable dependency graph according to error stack information thrown by the runtime and variable dependency relationships in the source code; obtaining a repair patch candidate set, performing functional verification on the repair patch candidates in an isolated sandbox, generating patch efficiency based on the verification results, and comparing it with a preset threshold; for patch candidates whose patch efficiency meets preset conditions, injecting the current runtime environment to replace the original code logic; for patch candidates whose patch efficiency does not meet preset conditions, marking them for manual review.

[0013] The application further provides that step S6 comprises: According to the repair patch applied to the running environment, the line numbers of corresponding source files before and after the patch are located; An entry probe and an exit probe are implanted at the line number through code instrumentation, and time points and call events before and after patch execution are recorded; The runtime captures an initial timestamp at the entry probe and a termination timestamp at the exit probe, and accumulates call counts; The timestamp difference and the call count are periodically transmitted to the performance analysis module through the communication channel, the corresponding breakpoint weight is updated, and the subsequent breakpoint priority and triggering strategy are adjusted according to the updated weight.

[0014] The application further provides that step S7 comprises: The difference coverage, breakpoint mapping accuracy and patch efficiency are obtained, a debugging comprehensive score is calculated, and the comprehensive score is compared with a preset quality threshold; When the comprehensive 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; A debugging end event is notified through the established communication channel, and a debugging interface is called to cancel all breakpoints and close the debugging port; The performance probe sampling service is stopped and the buffered data is cleared, the WebSocket communication channel is closed, and the debugging daemon process in the isolated sandbox is destroyed; All temporary snapshots and patch files are archived or deleted, and the isolated sandbox is restored to the initial state.

[0015] The application also provides a server-side Javascript development debugging system for implementing the above-mentioned server-side Javascript development debugging method, and the system comprises: An environment deployment module: deploying a GraalVM running environment and configuring an isolated sandbox, and establishing a bidirectional communication channel with the isolated sandbox through WebSocket; A first calculation module: calculating the difference coverage between the local and the server, and performing hot difference injection or complete reloading of the script file; A second calculation module: based on historical debugging logs, source code complexity and real-time performance probe data, a high-order tensor model is constructed, breakpoint candidate positions are refined, breakpoint mapping accuracy is calculated, and the breakpoint is mapped and registered to the debugging engine; A conflict monitoring module: monitoring the execution path conflict distribution and triggering self-healing rollback based on an entropy increase rate threshold, restoring to the last stable snapshot and returning to S2; A patch generation module: obtaining a repair patch candidate set, verifying the repair patch candidate, calculating the patch efficiency, and applying the repair patch when the preset condition is met; A weight adjustment module: implanting a lightweight performance probe before and after the repair patch, collecting the delay and call frequency and adjusting the breakpoint weight; Debugging quantitative module: calculate the debugging comprehensive score based on the difference coverage, breakpoint mapping accuracy and patch efficiency, quantify the debugging quality, when greater than the preset threshold, end the debugging and disconnect the debugging session, release the resources.

[0016] The application provides a server-side Javascript development debugging system and method, the method deploys GraalVM running environment and configures isolated sandbox, establishes a two-way communication channel with the isolated sandbox through WebSocket; calculates the difference coverage between the local and the server, performs hot difference injection or complete reloading of the script file; based on historical debugging logs, source code complexity and real-time performance probe data, constructs a high-order tensor model, refines breakpoint candidate positions, calculates breakpoint mapping accuracy, maps and registers to the debugging engine; monitors execution path conflict distribution and triggers self-healing rollback based on the entropy increase rate threshold, restores to the last stable snapshot, returns to S2; obtains a repair patch candidate set, verifies the repair patch candidate, calculates the patch efficiency, and applies the repair patch when the preset condition is met; implants a lightweight performance probe before and after the repair patch, collects latency and call frequency and adjusts the breakpoint weight; calculates the debugging comprehensive score based on the difference coverage, breakpoint mapping accuracy and patch efficiency, quantifies the debugging quality, when greater than the preset threshold, ends the debugging and disconnects the debugging session, releases the resources, and the beneficial effects include: 1. Safe isolation and efficient hot update: based on the GraalVM sandbox environment and the hot patch injection driven by the difference coverage, the script can be dynamically updated without restarting the running instance, which not only ensures the safety of debugging isolation, but also greatly shortens the patch verification and deployment time; 2. Intelligent breakpoint and self-healing rollback: the high-order tensor model automatically refines the breakpoints and monitors the execution path conflict entropy in real time, significantly improves the breakpoint hit rate and debugging accuracy; when the abnormality is concentrated or the conflict is too high, it automatically rolls back to the stable snapshot, maintains the continuity and reliability of the debugging environment; 3. Automatic patch generation and quality quantification: verify the repair patch candidate, combine the dynamic probe feedback and the comprehensive scoring method of geometric aggregation to realize adaptive patch application and quantifiable debugging quality evaluation, significantly improve the debugging efficiency and controllability of the results.

[0017] The above description is only a summary of the technical solutions of the application, in order to more clearly understand the technical means of the application, the specific embodiments of the application can be implemented according to the content of the specification, and in order to make the above and other purposes, features and advantages of the application more obvious and easy to understand, the following specific embodiments of the application are described. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly introduced. Obviously, the drawings in the following description only constitute some embodiments of the present application. Based on these drawings, other drawings can be obtained by those skilled in the art without any creative effort. In the drawings: Figure 1 A flow chart of a method for server-side Javascript development and debugging is shown for an exemplary embodiment of the present application; Figure 2 A structural schematic diagram of a system for server-side Javascript development and debugging is shown for an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0019] The embodiments of the present application will be described hereinafter with reference to the drawings and preferred embodiments, and other advantages and effects of the present application can be easily understood by those skilled in the art from the contents disclosed in the present specification. The present application can also be implemented or applied by different specific embodiments, and various modifications or changes can be made to the details in the present specification based on different views and applications without departing from the spirit of the present application. It should be understood that the preferred embodiments are only for illustrating the present application, but not for limiting the protection scope of the present application.

[0020] It should be noted that the diagrams provided in the following embodiments only schematically illustrate the basic concept of the present application, and the diagrams only show the components related to the present application, but not the number, shape and size of the components when actually implemented. The type, number and proportion of the components when actually implemented can be arbitrarily changed, and the layout type of the components can also be more complex.

[0021] In the following description, a large number of details are discussed to provide a more thorough explanation of the embodiments of the present application, however, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details, and in other embodiments, the known structures and devices are shown in the form of block diagrams instead of details, to avoid making the embodiments of the present application difficult to understand.

[0022] Embodiment one A method for server-side Javascript development and debugging, as shown in Figure 1 , comprising: S1: deploying GraalVM running environment and configuring isolated sandbox, and establishing a bidirectional communication channel with the isolated sandbox through WebSocket; S2: calculating the difference coverage between the local and the server, and performing hot difference injection or complete reloading of the script file; 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; S4: Monitor execution path conflict distribution and trigger self-healing rollback based on entropy increase rate threshold, restore to the last stable snapshot, and return to S2; S5: Obtain a set of repair patch candidates, verify the repair patch candidates, calculate patch efficiency, and apply the repair patch when the preset condition is met; S6: Implant lightweight performance probes before and after the repair patch, collect latency and call frequency and adjust breakpoint weights; 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.

[0023] The application further provides that step S1 comprises: The GraalVM distribution package is deployed in the server file system predefined path, an isolated sandbox instance is created, and the script project directory and the breakpoint directory are mapped; Specifically, the GraalVM distribution package is decompressed and installed in the predefined path of the server file system, and the binary and library files are ensured to be complete; The system environment variable is configured, so that the JavaScript runtime in GraalVM can be called by inputting the js command in any terminal or script; The permissions of the directory and its subdirectories are limited to only readable and executable for the debugging user group through the operating system permission management, so as to prevent unauthorized processes or users from modifying the runtime files; An independent namespace is created by using container technology or lightweight virtualization, and the sandbox is isolated from the host system at the process, file system and network level; The script project directory and the breakpoint directory are respectively mounted to the corresponding path in the container in read-only or read-write mode, so as to ensure that the source code and the test patch have strict read-write boundaries; The system call whitelist and network access control are imposed on the processes in the sandbox through the security policy engine, and only necessary operations related to debugging are allowed; The system call and network access of the sandbox process are limited through the security policy engine, and only the WebSocket listening port is opened; The WebSocket server is started inside the sandbox, listens to the preset port and loads the message distribution module; Specifically, the WebSocket server is started inside the isolated sandbox, listens to the preset port, and the server uses an asynchronous I / O framework to respond to multiple concurrent connections; The message distribution module is loaded, which dispatches file pulling, file saving and starting debugging instructions to each function processor according to the received JSON-RPC or custom message type; The WebSocket port is bound to the sandbox network interface, and the firewall rule is set to only allow connections from the debugging client IP or network segment to pass through; After the debugger initiates a WebSocket connection request locally, the server verifies the identity credentials and returns a summary of the project structure. After receiving the confirmation message, it establishes a persistent communication channel with the sandbox. Specifically, the debugging plug-in initializes locally and initiates a WebSocket connection request to the server sandbox. The connection message carries metadata such as identity credentials and project root path. After receiving the handshake request, the server verifies the identity credentials and returns a confirmation message of the project directory structure and file summary list. 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 debugging command interaction.

[0024] The present invention is further configured such that step S2 includes: In the local workspace, the target script file is divided into several data blocks of fixed length, and the content digest is calculated for each of them. Specifically, the local target script is divided into multiple consecutive data blocks according to a preset byte or line length, and the content digest is calculated for each data block to obtain a unique identifier for the consecutive data blocks, thereby avoiding the need to transfer the entire file and facilitating efficient comparison and location of the modified area. Request a data block summary list of the corresponding script file from the isolated sandbox through the established two-way communication channel. Specifically, send the script file path to the isolated sandbox through the established WebSocket channel. The sandbox reads the corresponding script and divides the data blocks according to the same rules. After calculating the summary, it returns the entire summary list to ensure consistency between the local and remote summary formats and block boundaries. Compare local and server data block summaries one by one to calculate the difference coverage. Specifically, compare the local and remote summary lists one by one, and count the ratio of the number of completely matched data blocks to the total number of remote blocks to obtain the difference coverage. A high coverage indicates that most of the code has not been modified, and only the new or changed parts need to be injected into the runtime. A low coverage means that the overall script is too different and is not suitable for local updates. The present invention is further configured such that the calculation logic of the difference coverage is: , is the difference coverage, is the number of local data blocks, is the number of server data blocks, For the The digest value of the local data block, For the The digest value of the server data block, is a very small positive number; specifically, based on the summary difference metric at the data block level, the degree to which the current local modification covers the remote script is quantified by calculating the ratio of the sum of the absolute differences between the local and server summaries of all data blocks and the sum of the server summaries. The smaller the ratio, the less the local modification and the higher the coverage; otherwise, a full reload is required. Finally, the difference coverage rate is obtained by "1 minus the ratio" , such that The closer to 1 indicates higher coverage; a very small positive number The value range is 10 −6 to 10 −12 , used to prevent division by zero errors when all server summaries are zero, while the result is negligible; the above calculation logic can accurately determine which data blocks have been modified without restarting the entire runtime instance, and only the modified part is executed dynamically, greatly reducing the context reconstruction overhead; At the same time, the full reload option is retained, which automatically switches to complete 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 achieving safe and efficient script updating and debugging; When the difference coverage rate is greater than or equal to the preset threshold, the local newly added or updated data block content is extracted and dynamically loaded into the runtime context through the GraalVM Polyglot API; Specifically, when the coverage rate reaches or exceeds the preset threshold, all data block contents corresponding to the unmatched summaries are extracted from the local, and these fragments are dynamically loaded into the current execution context through the GraalVM Polyglot API. The Polyglot API allows new code fragments to be injected into the JavaScript engine in the sandbox without restarting the entire runtime, and automatically updates the function or variable definition; When the difference coverage rate is less than the preset threshold, terminate the current runtime instance, reload the complete script file and start a new execution context; Specifically, if the coverage rate is less than the threshold, the current runtime instance is safely terminated first, and all memory and resources are released; Then reload the complete script file in an isolated sandbox and start a new execution context to ensure that the execution environment and the latest code are completely consistent, while restoring previously registered breakpoints and debugging state.

[0025] The application further provides that step S3 comprises: Collecting historical debugging logs, source code complexity indicators and runtime performance probe data to build a three-order tensor model; specifically, in the N code blocks contained in the script to be analyzed, in the historical debugging logs, two types of features are extracted for each code block: the number of exceptions and the number of calls, to form a matrix L (behavior N, column F1 is 2), in the source code complexity, the cyclomatic complexity (Cyclomatic Complexity) is extracted to form a vector C (behavior N, column F2 is 1), and the runtime performance probe collects two samples at the entrance and exit of each function: the average delay at the entrance and the average delay at the exit, to form a matrix P (behavior N, column F3 is 2); a three-order tensor X (the first dimension is N, the second dimension is F1+F2=3, and the third dimension is F3=2) is constructed, for each code block index , the second dimension index and the third dimension index , the definition is: , that is, the log features or complexity indicators and the performance data are completely fused in the same tensor along the probe dimension . High-order singular value decomposition is performed on the three-order tensor model to obtain the code block index corresponding to the dominant mode of the tensor; specifically, the tensor dimensions correspond to the log feature items, the complexity dimensions and the probe sampling points in turn; the three are aligned according to the same index, the tensor elements are filled, and the cross mapping of each code block in the three data spaces is ensured; HOSVD is performed on the constructed tensor to decompose the core tensor and three factor matrices ; according to the size of the singular value, the mode index corresponding to the first significant component is selected . The code block index is mapped to the source file line number, and the line that cannot be set as a breakpoint is removed; specifically, the extracted code block index is mapped to the specific source file and line number range; the mapped line number is checked for syntax, the comment, blank line and declaration line that cannot be set as a breakpoint are removed, and the final candidate breakpoint position is obtained; The mapping accuracy of the mapped line number and the runtime bytecode offset is verified, the breakpoint mapping accuracy is calculated, the candidate breakpoints higher than the preset threshold are retained, and the debugging engine interface is called to register the candidate breakpoints in the runtime environment; specifically, the candidate line number is mapped to the offset of the bytecode after GraalVM compilation; the difference between the expected offset and the actual offset is compared, and the mapping accuracy is calculated; only the breakpoints with an accuracy higher than the preset threshold are registered to ensure that the breakpoints hit accurately in the runtime; the GraalVM debugging interface is called to set breakpoints for each qualified breakpoint position in the runtime environment in the isolated sandbox; the registration result is fed back to the IDE plug-in, the local breakpoint view is updated, and the debugging session is prepared to enter.

[0026] The application further provides that step S4 comprises: At each execution branch entrance and key code segment, a conflict probe is implanted, and a conflict event is collected in real time; specifically, at the entrance of each execution branch and the key code segment, a probe code segment is inserted to capture and record the conflict or competition event at the 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 of each branch for subsequent distribution analysis; Based on the conflict event distribution, the entropy increase rate is calculated and compared with the preset threshold and the single-path conflict threshold; specifically, based on the conflict count of each branch, a probability distribution is constructed, and the conflict entropy increase rate is calculated to quantify the concentration degree of conflict events among paths; 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; When the entropy increase rate or the conflict count of any path exceeds the preset threshold, the current debugging instance is suspended, and the runtime context is saved; specifically, when the entropy increase rate or the conflict count of any path exceeds the corresponding threshold, the current debugging instance is immediately suspended, and the runtime context, including global variables, call stack and temporary state, is saved to memory or persistent cache; Restore to the last stable snapshot, including restoring the script file state, patch injection point and breakpoint registration information; specifically, restore the script file version, injected patch segment position and current breakpoint registration information from the last saved stable snapshot; clear the residual state in the running to ensure that the execution context after recovery is consistent with that at the snapshot time; Rebuild the isolated sandbox execution context, reload the latest script snapshot and register breakpoints, and return to step S2 to re-execute the difference coverage calculation and hot difference injection or complete reloading; specifically, reinitialize the execution environment in the isolated sandbox, load the restored script snapshot and re-register the breakpoints to restore the original debugging session structure; re-activate the performance probe and debugging communication channel to complete the context reconstruction; automatically jump to step S2 to re-calculate the local and server difference coverage, and execute hot difference injection or complete reloading according to the result to enter a new debugging iteration.

[0027] The application further provides that step S5 comprises: According to the error stack information thrown at runtime and the dependency relationship between variables in the source code, a variable dependency graph is constructed; specifically, the function name, line number and call chain of the exception occurrence are extracted from the error stack thrown at runtime; the variable definition and use relationship in the function or module related to the exception are parsed at the source code level to construct a directed graph structure with variables as nodes and dependency relationships as edges, reflecting the data flow and control dependency; A set of repair patch candidates is obtained, and functional verification is performed on the repair patch candidates in an isolated sandbox. Based on the verification results, a patch efficiency is generated for the patch candidates and compared with a preset threshold. Specifically, the patch candidates in the repair patch candidate set are sequentially applied to the runtime environment of the isolated sandbox, and regression testing is performed under the original test cases or predefined verification scripts. The verification process mainly detects whether the patch can eliminate the original anomaly and ensures that no new errors are introduced or normal logic is damaged. The patch efficiency is calculated based on the repair effect and verification overhead of each patch during the verification process. The patch efficiency is compared with a preset threshold to screen out patch candidates that are both efficient and safe. In a feasible embodiment of the present invention, the calculation logic of the patch efficiency is as follows: , Patch efficiency is used to evaluate the overall effectiveness of automatically generated patches. It is the patch candidate number index, used to distinguish multiple automatically synthesized repair patches. For the The execution time saved by a patch in an isolated verification environment to eliminate the original error, that is, the difference in the execution time of the test case or script before and after the patch is applied, For the The time it takes to verify the functionality of a patch, which usually includes the time it takes to execute the verification scripts or test cases. For patch candidates whose patch efficiency meets the 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. Patch candidates whose patch efficiency does not meet the preset conditions are marked for manual review. Specifically, for patches whose efficiency does not meet the standards, the patch code and verification report are retained and submitted to the developer for manual review and adjustment.

[0028] The present invention is further configured such that step S6 includes: Locate the corresponding source file line numbers before and after the patch applied to the runtime environment; specifically, obtain the line number range of the patch start and end in the source file based on the applied patch information; determine the line numbers corresponding to key positions before and after the patch to provide accurate positioning for probe insertion, including entry points and exit points; The entry probe and the exit probe are implanted at the line number by code instrumentation, and the time points before and after patch execution and the call events are recorded; specifically, an entry probe code segment is inserted at the entry line number, which is used to record the initial timestamp before patch execution and the call context; an exit probe code segment is inserted at the exit line number, which is used to record the termination timestamp after patch execution and incrementally update the call count; the probe insertion is completed through abstract syntax tree (AST) modification or GraalVM Polyglot API, ensuring seamless integration with the original logic and extremely low overhead; The runtime captures the initial timestamp at the entry probe and the termination timestamp at the exit probe, and accumulates the call count; specifically, the initial timestamp and the unique probe identifier are captured and locally stored at the entry probe; the termination timestamp is captured at the exit probe, and the difference between the two is obtained to obtain the single delay, while the call count of the probe is accumulated; the above information is cached in the form of (unique probe identifier probeId, single delay Δt, accumulated call count count) in the memory or a lightweight message queue; The timestamp difference and the call count are periodically transmitted to the performance analysis module through the communication channel, and the corresponding breakpoint weight is updated, and the subsequent breakpoint priority and triggering strategy are adjusted according to the updated weight; specifically, the buffered data packets are sent to the performance analysis module through the existing WebSocket channel at a fixed time or according to a fixed data volume threshold; the analysis module maps each record to the corresponding breakpoint entry according to the probeId, and calculates the delay distribution and the call frequency change of the next round; the weight value of the breakpoint is updated according to the predetermined algorithm, which includes the weight value gain algorithm based on the delay amplitude and the frequency improvement, specifically including: The average delay recorded by the probe at the last weight update And the call frequency As the baseline; the current average delay collected from the probe this time is recorded as , and the current call frequency is recorded as ; the delay amplitude ratio is defined as: , which is used to quantify the degree of performance degradation under the influence of the patch or the breakpoint; the frequency improvement ratio is defined as , which is used to measure the change in execution heat of the breakpoint code block, is a very small positive number, and the delay amplitude ratio applies a nonlinear mapping function to compress the positive delay amplitude to the interval (0, 1); for the frequency improvement ratio , an exponential mapping function is applied, , is an adjustment coefficient, so that the faster the frequency grows, the closer the mapping value is to 1; the total gain coefficient is defined as , wherein , are the adjustment coefficients of the delay and frequency mapping respectively, used to control the contribution degree of each to the weight, and the new weight value is obtained by multiplying the original weight and the gain coefficient to obtain: The updated weight is immediately written back to the debugging daemon process or plug-in for adjusting the subsequent breakpoint priority and trigger strategy. The debugging daemon adjusts the subsequent breakpoint priority and trigger strategy according to the updated weight; specifically, the updated weight value is issued to the debugging daemon process or IDE plug-in through RPC or event pushing; the daemon process or plug-in adjusts the priority ordering and trigger condition of the subsequent breakpoint list after receiving, including skipping low-weight breakpoints or stopping at high-weight breakpoints in advance, optimizing the debugging flow.

[0029] The application further provides that step S7 comprises: The difference coverage, breakpoint mapping accuracy and patch efficiency are obtained, and a debugging comprehensive score is calculated and compared with a preset quality threshold; specifically, the final difference coverage is read from the hot difference injection module; the average breakpoint mapping accuracy is obtained from the breakpoint registration module; the patch efficiency of the applied patch is obtained; the three indicators are mapped to a comprehensive score according to the predetermined geometric aggregation or other nonlinear combination strategy, and the geometric aggregation or other nonlinear combination strategy is not limited here and 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 end condition; When the comprehensive 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 comprehensive score is not lower than the threshold, a session termination instruction is sent to the debugging engine in the sandbox to trigger the script execution interruption; the debugging engine stops all debugging threads immediately after responding to ensure that the script is no longer executed; The debugging end event is notified through the established communication channel, and the debugging interface is called to cancel all breakpoints and close the debugging port; specifically, all registered breakpoints are cancelled through the debugging interface; the debugging port is closed, and the connection with the GraalVM debugging sub-process is disconnected; The performance probe sampling service is stopped and the buffer data is cleared, the WebSocket communication channel is closed, and the debugging daemon process in the isolated sandbox is destroyed; specifically, the performance probe sampling service is stopped, and the probe buffer data in the local and sandbox is emptied; the WebSocket communication channel is closed, and the bidirectional connection with the IDE plug-in is disconnected; All temporary snapshots and patch files are archived or deleted, and the isolated sandbox is restored to the initial state; specifically, the debugging daemon process is destroyed, and the computing and memory resources of the sandbox instance are released; the temporary snapshots and patch files are archived or deleted; the sandbox file system is reinitialized and restored to the initial code version and blank patch directory.

[0030] By unifying the core indicators and automatically determining whether the debugging meets the predetermined quality, the application can objectively and timely end the high-quality debugging session, avoid the randomness and errors of manual judgment, and ensure that the debugging environment returns to the initial state after each end to provide a clean and controllable basic environment for subsequent debugging, thereby significantly improving the efficiency, security and repeatability of remote debugging.

[0031] Embodiment two Referring to Figure 2 The exemplary server-side Javascript development debugging system is used to implement the above-mentioned server-side Javascript development debugging method, and the system comprises: An environment deployment module is configured to deploy a GraalVM running environment and configure an isolated sandbox, and to establish a bidirectional communication channel with the isolated sandbox through a WebSocket; A first calculation module is configured to calculate the difference coverage between the local and the server, and to perform hot difference injection or complete reloading of the script file; A second calculation module is configured to construct a high-order tensor model based on historical debugging logs, source code complexity and real-time performance probe data, to extract breakpoint candidate positions, to calculate breakpoint mapping accuracy, and to map and register to a debugging engine; A conflict monitoring module is configured to monitor the execution path conflict distribution and trigger self-healing rollback based on an entropy increase rate threshold, to restore to the last stable snapshot and return to S2; A patch generation module is configured to obtain a repair patch candidate set, to verify the repair patch candidate, to calculate patch efficiency, and to apply the repair patch when the preset condition is met; A weight adjustment module is configured to implant a lightweight performance probe before and after the repair patch, to collect the delay and call frequency and to adjust the breakpoint weight; A debugging quantification module is configured to calculate a comprehensive score of debugging based on the difference coverage, the breakpoint mapping accuracy and the patch efficiency, to quantify the debugging quality, and to end the debugging and disconnect the debugging session when the comprehensive score is greater than a preset threshold, and to release the resources.

[0032] It should be noted that the server-side Javascript development debugging system provided by the above embodiment and the server-side Javascript development debugging method provided by the above embodiment belong to the same concept, wherein the specific operation execution manner of each module and unit has been described in detail in the method embodiment, which will not be repeated here. The server-side Javascript development debugging system provided by the above embodiment can allocate the above functions to different functional modules according to the needs in the actual application, that is, the internal structure of the system is divided into different functional modules to complete all or part of the functions described above, and this is not limited herein.

[0033] The above-described embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, the above-described embodiments can be implemented in the form of 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, the processes or functions described in the embodiments of the present application are wholly or partially generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another, for example, the computer instructions can be transferred from one website, computer, server, or data center to another via wired (for example, infrared, wireless, microwave, etc.) or wireless means. The computer-readable storage medium can be any available medium accessible by a computer or a data storage device such as a server, data center, or the like, which includes one or more available medium collections. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state disk.

[0034] It should be understood that the term "and / or" herein merely describes an association relationship of associated objects, which means that there can be three relationships, for example, A and / or B can represent the following three cases: A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural. In addition, the character " / " herein generally represents an "or" relationship between the associated objects before and after it, but it can also represent an "and / or" relationship. The specific meaning can be understood according to the context before and after it.

[0035] In this application, "at least one" means one or more, and "multiple" means two or more. "At least one of the following" or the like means any combination of the items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, and c can be single or multiple.

[0036] It should be understood that in various embodiments of the present application, the size of the sequence number of the above-described processes does not mean the order of execution, and the execution order of the processes should be determined according to their functions and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0037] Those skilled in the art can clearly understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed 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 the present application.

[0038] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

[0039] In several embodiments provided in the present application, it should be understood that the disclosed system can be implemented in other ways. For example, the above-described device embodiments are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0040] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0041] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0042] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0043] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for developing and debugging Javascript on a server side, characterized in that: include: S1: Deploy the GraalVM runtime environment and configure an isolated sandbox. Establish a two-way communication channel with the isolated sandbox via WebSocket. S2: Calculates the difference coverage between the local and server versions, and performs hot difference injection or complete reload of script files; S3: Based on historical debugging logs, source code complexity, and real-time performance probe data, it builds a high-order tensor model, extracts candidate breakpoint locations, calculates breakpoint mapping accuracy, and registers 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, restoring to the last stable snapshot and returning to S2. 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 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 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, debugging is terminated and the debugging session is disconnected to release resources.

2. A server-side Javascript development and debugging method according to claim 1, characterized in that: Step S1 includes: Deploy the GraalVM distribution package to a predefined path on the server file system, create an isolated sandbox instance, and map the script project directory and patch directory. The security policy engine restricts sandbox process system calls and network access, leaving only the WebSocket listening port open. Start the WebSocket server inside the sandbox, listen to the preset port and load the message distribution 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. A server-side Javascript development and debugging method according to claim 1, characterized in that: Step S2 includes: Divide the target script file into several data blocks of fixed length in the local workspace and calculate the content summary for each block; Requesting a data block summary list of the corresponding script file from the isolated sandbox through the established bidirectional communication channel; Compare the local and server data block summaries one by one and calculate the difference coverage; When the difference coverage is greater than or equal to the preset threshold, the local newly added or updated data block content is extracted and dynamically loaded into the runtime context through the GraalVM Polyglot API; When the difference coverage falls below a preset threshold, the current runtime instance is terminated, the complete script file is reloaded, and a new execution context is started.

4. A server-side Javascript development and debugging method according to claim 3, characterized in that: The calculation logic of difference coverage is: , is the difference coverage, is the number of local data blocks, is the number of server data blocks, For the The digest value of the local data block, For the The digest value of the server data block, is a very small positive number.

5. A server-side Javascript development and debugging method according to claim 1, characterized in that: Step S3 includes: Collect historical debugging logs, source code complexity indicators, and runtime performance probe data to build 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's dominant mode; Map code block indexes to source file line numbers, excluding lines where breakpoints cannot be set; The mapped line number and runtime bytecode offset are verified for accuracy, the breakpoint mapping accuracy is calculated, candidate breakpoints above the preset threshold are retained, and the debugging engine interface is called to register the candidate breakpoints in the runtime environment.

6. A server-side Javascript development and debugging method according to claim 1, characterized in that: Step S4 includes: Conflict probes are implanted at each execution branch entry and key code segment to collect conflict events in real time; Calculate the entropy increase rate based on the conflict event distribution and compare it with the preset threshold and the single-path conflict threshold; When the entropy increase rate or any path conflict count exceeds the preset threshold, the current debugging instance is paused and the runtime context is saved; Restore to the last stable snapshot, including restoring script file status, 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 differential coverage calculation and hot differential injection or complete reload.

7. A server-side Javascript development and debugging method according to claim 1, characterized in that: Step S5 includes: Build 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 isolated sandbox, generate patch efficiency for the patch candidates based on the verification results, and compare it with a preset threshold; For patch candidates whose patch efficiency meets the preset conditions, inject them into the current running environment; For patch candidates whose patch efficiency does not meet the preset conditions, they are marked for manual review.

8. A server-side Javascript development and debugging method 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 repair patch applied to the running environment; Insert entry and exit probes at the line number through code instrumentation to record the time points and call events before and after the patch is executed; 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; The timestamp difference and call count are regularly transmitted to the performance analysis module through the communication channel, the corresponding breakpoint weight is updated, and the subsequent breakpoint priority and triggering strategy are adjusted according to the updated weight.

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

10. A server-side Javascript development and debugging system, used to implement the server-side Javascript development and debugging method according to any one of claims 1 to 9, characterized in that: include: Environment deployment module: deploys the GraalVM runtime environment and configures an isolated sandbox, establishing a two-way communication channel with the isolated sandbox via WebSocket. The first calculation module calculates the difference coverage between the local and server, and performs hot difference injection or complete reload of script files; The second computing module: Based on historical debugging logs, source code complexity, and real-time performance probe data, it builds a high-order tensor model, extracts candidate breakpoint locations, calculates breakpoint mapping accuracy, and registers the mapping to the debugging engine. Conflict monitoring module: monitors the distribution of execution path conflicts 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 repair patch candidates, verifies the repair patch candidates, calculates the patch efficiency, and applies the repair patch when the preset conditions are met; Weight adjustment module: This module implants lightweight performance probes before and after patch repairs to collect latency and call frequency and adjust breakpoint weights. Debug 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, debugging is terminated and the debugging session is disconnected to release resources.

Images