Function unloading method and system based on Java language runtime

Abstract

The invention provides a function unloading method and system based on Java language runtime, and the method comprises the steps: loading and reading a byte code file, and obtaining a screened file; a user-defined function is screened out through annotations, instrumentation is carried out on the function, codes for information collection during operation are added, and then the user-defined function after instrumentation is converted into a byte array; converting the byte array into a new byte array, and storing the new byte array; judging whether CPU resource occupation is higher than a preset value or not when the function runs; if the result is yes, screening and marking the candidate function, and unloading the candidate function; and if not, not processing. According to the method, the non-perception computing platform characteristic of the server is utilized, on the premise that the operation and maintenance operation of a bottom-layer server is not concerned, the capacity of the application can be rapidly expanded and shrunk according to needs, so that local system resources are saved, the CPU utilization rate can be saved to 60% or above after user function unloading is started, and expandability is improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of function offloading of server-unaware computing, and specifically relates to a function offloading method and system based on Java language runtime, and more specifically, to a function offloading strategy and technology based on Java language runtime. Background Art

[0002] The development of cloud computing has spawned new technologies that have changed traditional IT architecture and operation and maintenance methods, such as virtual machines, containers, and microservices. The emergence of server-aware computing has brought new changes by outsourcing all components of host management, operating system management, resource allocation, capacity expansion, and even application logic.

[0003] The existing system is based on server-aware computing, which automatically offloads functions that occupy large local resources to the server-aware computing platform, thereby improving the scalability of existing applications. The current work mainly includes the analysis and optimization of the server-aware computing system itself, making the existing application server-aware, and building and training server-aware computing models designed for specific scenarios.

[0004] At present, existing technical solutions have analyzed and optimized the server-aware computing system itself from many aspects.

[0005] For example, the Photons system implemented by Vojislav et al. places multiple instances of the same function in server-aware computing in the same runtime, thereby improving cross-function communication performance and reducing function memory overhead; the IceBreaker system implemented by Rohan et al. improves the hot start performance of server-aware computing based on heterogeneous nodes, thereby reducing service time and saving cost overhead.

[0006] This type of work improves the startup, execution, and communication performance of the server-aware computing system itself, and provides a basic guarantee for existing applications to use the server-aware platform for computing. Regarding the work of making existing applications server-aware, it is mainly aimed at computing-intensive and resource-intensive application types, and a specialized computing framework is designed. This is completed by rewriting applications for server-aware computing, so as to take advantage of server-aware computing to accelerate existing applications and reduce computing costs.

[0007] For example, the gg framework designed and implemented by Sadjad et al. designed an execution engine and provided easy-to-use command line tools to help users use server-aware computing to execute daily applications such as software compilation. The ExCamera system designed and implemented by Sadjad's team applies server-aware computing in the field of video processing, reducing the latency of video-related operations such as encoding videos.

[0008] However, for complex stateful online services that are tightly coupled with the framework, similar methods require a lot of code modification and refactoring, which cannot be easily implemented. Therefore, it is very necessary to add a more reasonable selection mechanism to guide the system to select a more reasonable and efficient unloading target when unloading functions.

[0009] In terms of computing offloading selection strategies, there are some existing computing offloading works that include selection strategies and mechanisms. For example, the MAUI system proposed by Eduardo et al. attempts to use edge computing nodes to offload applications executed in mobile devices at the granularity of functions, abstracting the function selection strategy into a linear programming problem based on certain rules. The CloneCloud system proposed by Byung et al., facing the same scenario, introduces static analysis and more complex linear programming conditions to achieve more accurate function selection.

[0010] In general, for scenarios with high concurrent client requests, the user-side latency will increase with the number of requests, resulting in increased request latency. In addition, there is currently no relevant work specifically aimed at selecting functions suitable for offloading to the server-aware computing platform, so the collection of runtime information, such as what information should be collected, how to collect the information in this paper, and how to use the information after collection to select user functions that are truly suitable for offloading, still needs to be analyzed and explored. Existing solutions such as the Photons system implemented by Vojislav et al. and the gg framework designed and implemented by Sadjad et al. have improved performance to a certain extent, but they are not general solutions for scenarios with high concurrent client requests. In addition, the existing solutions require the introduction of a large number of code modifications and refactorings, and cannot provide a general solution for similar requirements and scenarios. This problem needs to be solved urgently. Summary of the invention

[0011] In view of the defects in the prior art, the object of the present invention is to provide a function unloading method and system based on Java language runtime.

[0012] A method for unloading a function based on Java language runtime provided by the present invention includes:

[0013] Step S1: Load and read the bytecode class file, and filter it according to the class name to obtain the filtered file;

[0014] Step S2: According to the filtered files, filter and insert user-defined functions through annotations, and convert the inserted user-defined functions into byte arrays;

[0015] Step S3: converting the byte array into a new byte array; the new byte array is represented by the bytecode of the Java class, and saving the new byte array;

[0016] Step S4: when the function is running, determine whether the CPU resource usage is higher than the preset value; if the result is yes, filter and mark the candidate functions, store the candidate functions in a constant-level array, and unload; if the result is no, do not process it.

[0017] Preferably, in step S1, the bytecode class file is loaded and read through the ClassReader class in the ASM framework;

[0018] Determine whether the class name contains the prefix specified by the user; if the result is yes, convert the bytecode class file into a byte stream, that is, the filtered file; if the result is no, skip it and do not process it.

[0019] Preferably, in step S2, the ClassVisitor class is used to filter out user-defined functions according to annotations;

[0020] The annotations are determined according to a framework, i.e., a software toolset;

[0021] The framework includes: a spring framework;

[0022] The annotations include: @GetMapping, @PostMapping, and @PutMapping.

[0023] Preferably, in step S3, the toByteArray method of the ClassWriter class is called to obtain a new byte array, and the new byte array is saved in a .class file; the .class file collects information when the Java program is running.

[0024] Preferably, in step S4, the preset value is set to 20%, and it is determined whether the CPU resource occupancy is higher than 20%; if the result is no, no processing is performed; if the result is yes and less than 50%, the candidate functions to be uninstalled are screened out, and the candidate functions are stored in a constant-level array, and it is further determined whether the CPU resource occupancy is greater than or equal to 50%; if the result is yes, the candidate functions are marked, and the candidate functions are uninstalled according to the uninstall rate set by the user; if the result is no, no processing is performed;

[0025] The candidate functions include: the most recently executed user function or the function with the longest average running time.

[0026] A function unloading system based on Java language runtime provided by the present invention includes:

[0027] Information collection module: load and read bytecode class files, and filter them according to class names to obtain filtered files; filter and insert user-defined functions through annotations according to the filtered files, convert the inserted user-defined functions into byte arrays, and convert the byte arrays into new byte arrays; the new byte arrays are represented by bytecodes of Java classes; and save the new byte arrays;

[0028] Function uninstallation policy module: When a function is running, it determines whether the CPU resource usage is higher than the preset value; if the result is yes, the candidate function is marked and uninstalled; if the result is no, no processing is performed.

[0029] Preferably, in the information collection module, the bytecode class file is loaded and read through the ClassReader class in the ASM framework;

[0030] Determine whether the class name contains the prefix specified by the user; if the result is yes, convert the bytecode class file into a byte stream, that is, the filtered file; if the result is no, skip it and do not process it.

[0031] Preferably, in the information collection module, the ClassVisitor class is used to filter out user-defined functions according to annotations;

[0032] The annotations are determined according to a framework, i.e., a software toolset;

[0033] The framework includes: a spring framework;

[0034] The annotations include: @GetMapping, @PostMapping, and @PutMapping.

[0035] Preferably, in the function unloading policy module, the toByteArray method of the ClassWriter class is called to obtain a new byte array.

[0036] Preferably, in the function uninstallation policy module, the new byte array is saved in a .class file; the .class file collects information when the Java program is running;

[0037] Let the preset value be 20%, and determine whether the CPU resource usage is higher than 20%; if the result is no, no processing is performed; if the result is yes and less than 50%, the candidate functions to be uninstalled are screened out, and the candidate functions are stored in a constant-level array, and further determine whether the CPU resource usage is greater than or equal to 50%; if the result is yes, the candidate function is marked and uninstalled according to the uninstall rate set by the user; if the result is no, no processing is performed;

[0038] The candidate functions include: the most recently executed user function or the function with the longest average running time.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] 1. The present invention utilizes the characteristics of the server-unaware computing platform. Without having to worry about the underlying server operation and maintenance, it can quickly scale the application on demand to save local system resources. After enabling user function unloading, the CPU utilization can be saved to more than 60%, thereby increasing scalability.

[0041] 2. The present invention is a non-perceptual function unloading, which can automatically unload the function to the non-perceptual platform of the remote server for operation without modifying the business code.

[0042] 3. After the system CPU utilization reaches 50%, the present invention can automatically traverse the user function unloading candidates and mark them accordingly. When these functions are run again, the functions will be directly unloaded. After automatic unloading, the average end-to-end delay can be reduced by 50%, reducing the request delay in the client's high-concurrency request scenario and improving performance.

[0043] 4. The present invention can increase scalability, is user-transparent, and can automatically select functions suitable for uninstallation, providing a general and automated solution for similar scenarios without introducing cumbersome targeted code modification and reconstruction. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0045] Figure 1 A schematic diagram of the execution flow of the runtime information collection module provided by the present invention;

[0046] Figure 2 A schematic diagram of the execution flow of the function unloading policy module provided by the present invention. DETAILED DESCRIPTION

[0047] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0048] The present invention provides a function unloading method based on Java language runtime, which can automatically filter out functions that consume large resources when the program is running without changing the user code, and unload them to the server non-perceptual computing platform. The runtime information of the user program is collected through the function unloading strategy, and then the function is selected based on this information to filter out the functions that consume large resources. Finally, the target function is written on the remote server non-perceptual computing platform.

[0049] like Figure 1 The figure shows the execution flow of the runtime information collection module of the present invention.

[0050] Combination Figure 1 The overall execution process of the runtime information collection module is described in detail:

[0051] Step S1: Load the bytecode class file, i.e., .class file, through the ClassReader class in the ASM framework, read the content, and preliminarily screen the user function according to classname, i.e., the class name.

[0052] Specifically, the user's .class file is obtained through the ClassReader instance, and the class name is filtered according to whether it contains the prefix specified by the user; that is, it is determined whether the class name contains the prefix specified by the user. If the result is yes, the bytecode class file is converted into a byte stream, that is, a byte array; if the result is no, the class is skipped and no processing is performed;

[0053] The successfully filtered classes are converted into byte streams and will be processed by the subsequent modules. A ClassVisitor instance is used for subsequent processing.

[0054] The ASM framework in step (1) is a Java bytecode manipulation framework, which can be used to dynamically generate classes or enhance the functions of existing classes. The ClassReader class is used to parse the compiled bytecode class file.

[0055] Java bytecode class files, i.e. .class files, are target files generated by the Java compiler when it compiles Java source files, i.e. .java files.

[0056] Step S2: According to the filtered files, user-defined functions are filtered out through annotations, and the functions are instrumented, codes for runtime information collection are added, and the user-defined functions are converted into byte arrays;

[0057] Specifically, the ClassVisitor class is used to filter out user-defined functions based on annotations, convert the parsed byte array, instrument the Java instructions, and add code for runtime information collection.

[0058] The ClassVisitor class in step (2) is a visitor of a class in Java, providing a series of methods to be called by ClassReader.

[0059] Specifically, at the Class level of the user code, each method under the Class is initially screened by judging whether the method meets the properties provided by the native method class. If the result is yes, it will be further screened at the Method level; if the result is no, the method will be skipped and not processed.

[0060] For example, determine whether the method is an abstract method, a Java native method, a constructor init or a static constructor clinit, etc., filter out the scope of a user function, and then sink the subsequent work to the Method level.

[0061] When entering a specific method, further screening is performed based on the annotations of the method;

[0062] The further filtering criteria depends on what framework the user uses. The framework is a software tool set that provides basic structure and ready-made functions to help developers build applications more easily. The annotations are a way to provide metadata for Java code. They can be used to provide additional information about the code and tell the compiler, tools or framework how to process the code. Frameworks widely use annotations to simplify the development process, and different frameworks define different annotations.

[0063] In other words, the annotation @GetMapping is one of the annotations used by the spring framework to process HTTP GET requests, which can map HTTP GET requests to specific processing methods, such as Controller methods.

[0064] For example, if the user uses the classic Spring framework, the annotations of the user request function are @GetMapping, @PostMapping, @PutMapping, etc. The user can filter out the user-defined functions based on the annotations.

[0065] After completing the screening work, the solution further adds some function temporary variables and class member variables for these user functions, records the runtime time and completes function reflection to obtain method variables, and finally passes these data as parameters to the runtime information collector.

[0066] The function temporary variables are variables declared inside the function. They only exist during the execution of the function and will be destroyed after the execution of the function. They are used to record the start and end time of the function.

[0067] Class member variables are variables defined in a class. They are part of the class. The life cycle of class member variables is the same as that of the class instance. They are used to record the running time of the function.

[0068] Considering the huge overhead caused by reflection, it is not possible to perform reflection every time a function is called to get the method instance of the user function. Therefore, consider adding static fields to the class where the user function is located to save the method instances of these user functions.

[0069] Step S3: Use the ClassWriter class to convert the byte array processed in step S2 into a byte stream of new content, and store the newly generated content in a specific .class file. Then, this new .class file has the function of collecting runtime information, and the ASM workflow ends here.

[0070] Specifically, the toByteArray method of the ClassWriter class is called to obtain a byte stream of the new content, that is, a byte array, which contains the bytecode representation of the Java class generated by the ClassWriter class.

[0071] The ClassWriter class in step 3 is used to rebuild the compiled class, for example, to modify the class name, attributes and methods, and to generate a bytecode file of a new class.

[0072] The .class file in step 3 is the bytecode file generated by the Java compiler compiling the Java source code;

[0073] Step S4: when the function is running, determine whether the CPU resource usage is higher than the preset value; if the result is yes, filter and mark the candidate functions, store the candidate functions in a constant-level array, and unload; if the result is no, do not process it.

[0074] Specifically, when the Java program application starts running, a daemon thread is started internally as a resource monitor to regularly obtain the local resource usage. The resource monitor accesses the / proc related files on the Linux system to obtain local resources.

[0075] If the CPU resource usage is higher than 20% and lower than 50%, candidate functions will be selected for uninstallation and stored in a constant-level array; if the CPU resource usage is lower than or equal to 20%, no processing will be done. If the CPU resource usage is greater than or equal to 50%, the candidate functions will be marked and uninstalled. There are two function selection strategies to choose from: the first is to select the most recently run user function for uninstallation; the second is to select the function with a longer average running time for uninstallation.

[0076] Specifically, when the user sets the uninstall rate to 50%, the candidate functions are sorted according to the average running time, and the first 50% of the candidate functions with the longest running time are uninstalled.

[0077] This method adopts the second average running time selection scheme by default.

[0078] Specifically, if the CPU resource usage is higher than 50%, the user function will be directly traversed from the maintained candidate function array and marked. If the CPU resource usage is lower than or equal to 50% and higher than 20%, the candidate function selection strategy will be used to select the candidate function, and the marked function will be offloaded to the serverless platform by the application layer.

[0079] Specifically, at the application level, the application checks whether the function is marked through the instructions injected in steps 1 to 4. If it is a marked function, the system will uninstall the user function according to the specific uninstall rate. Specifically, the default uninstall rate is set to a fixed 50%, that is, when the function uninstallation starts, half of the user functions will be uninstalled to the remote server non-aware computing platform.

[0080] A function unloading strategy and technology based on Java language runtime, including: a runtime information collection module and a function unloading strategy module;

[0081] Specifically, during runtime, the information collection module is used to filter out user functions and record the number of times and duration of user functions being run, and the function uninstallation strategy module selects and uninstalls candidate functions based on the data collected by the runtime information collection module.

[0082] The information collection module includes: a user function screening module, a user function timing module and an information collection and transmission module.

[0083] The user function screening module uses the built-in properties of the method in the JVM, or the transit function for function reflection in the application framework, or directly reads the .class file through the relevant library to obtain the corresponding annotations, screens all Java functions, and selects the functions written by the user.

[0084] The user function timing module is used to time the operation of the user function at the nanosecond level.

[0085] The information collection and transmission module adds corresponding native methods in the JVM and exposes the interface to the outside.

[0086] The function unloading strategy module includes: an information storage design module, a local resource monitoring module and a user function selection module.

[0087] The information storage design module uses a bidirectional linked list to store related information. The linked list nodes are divided into two parts, one is the pointer to the method method, and the other is the runtime information of the method.

[0088] The local resource monitoring module can monitor the CPU usage of the local machine.

[0089] The user function selection module can unload candidate functions one by one to the server non-aware computing platform after the local machine resource usage exceeds a set threshold.

[0090] like Figure 2 As shown, it is the flow chart of the function unloading strategy module of the present invention.

[0091] Combine the following Figure 2 A detailed description of the overall execution process:

[0092] Step S1: The JVM external interface specifically provides a way for the runtime information collector to connect to the outside world, which is mainly used to transfer method instances and related runtime information to the runtime information collector inside the JVM.

[0093] In other words, in step S1, the method instance and related runtime information are transferred to the runtime information collector inside the JVM;

[0094] Step S2: The local resource monitoring thread periodically monitors the resource consumption of the local machine; accesses / proc related files on the Linux system to obtain local resources.

[0095] Step S3: instructing the runtime information collector to use a bidirectional linked list data structure to store corresponding user function runtime information, and provide an interface to periodically trigger a monitoring thread of local resources;

[0096] Use a doubly linked list as the specific data structure of the collector;

[0097] In the specific implementation, first, a method instance and its related runtime information are packaged into a linked list node, and a timestamp is added to each linked list node. The specific setting of the time window is added to the linked list structure, and the data structure of the linked list is set as a friend of the node data structure, so that the member functions of both parties are inline functions of each other, avoiding excessive function stack switching, thereby improving the overall operation efficiency of the system.

[0098] Specifically, the specific process of information collection is as follows:

[0099] First, the information collector is used to determine whether the user function already exists in the bidirectional linked list. If the result is yes, that is, it already exists, then the process goes to step (2); if the result is no, that is, it does not exist, then the process goes to step (3);

[0100] Step (2): If the user function already exists, the runtime information and timestamp of the node will be updated, and after the update, the node will be moved to the head of the doubly linked list;

[0101] Step (3) If the user function does not exist in the existing bidirectional linked list, a new user function runtime information recording node will be created, including: the method instance of the user function, the number of times the user function is run and the running time, and a corresponding timestamp. After the new recording node is created, the node will be inserted into the header of the bidirectional linked list, completing the basic process of collecting user function runtime information.

[0102] From this we can see that the doubly linked list of the runtime information collector is an ordered doubly linked list with the most recent run timestamp as the sorting standard, that is, the most recently run function is located at the head of the doubly linked list, and the function that has not been run for a long time is located at the tail of the doubly linked list.

[0103] Step S4: When the local resource monitoring thread is triggered, the uninstall function selector in the present invention maintains a candidate list of functions to be uninstalled according to the information in the collector.

[0104] The uninstall function selector includes an uninstall function selection strategy part and a function uninstall execution part, which are used to select uninstall functions and execute uninstall. After waiting for the local machine resource load to reach 50%, the user function to be uninstalled will be directly obtained from the uninstall function candidate list, and finally the task of uninstalling the user function with high resource consumption to the remote server non-perceptual computing platform will be completed.

[0105] Specifically, when the JVM detects that the CPU utilization is higher than 20%, it selects candidate functions for unloading and stores them in a constant-level array. Then, when the CPU utilization is higher than 50%, it directly traverses the user functions in the maintained candidate function array and marks them. This operation is also a constant-level operation.

[0106] The present invention also provides a function unloading system based on Java language runtime, and the function unloading system based on Java language runtime can be implemented by executing the process steps of the function unloading method based on Java language runtime, that is, those skilled in the art can understand the function unloading method based on Java language runtime as a preferred implementation of the function unloading system based on Java language runtime.

[0107] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0108] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A function unloading method based on Java language runtime, characterized in that: include: Step S1: Load and read the bytecode class file, and filter it according to the class name to obtain the filtered file; Step S2: According to the filtered files, filter and insert user-defined functions through annotations, and convert the inserted user-defined functions into byte arrays; Step S3: converting the byte array into a new byte array; the new byte array is represented by the bytecode of the Java class, and saving the new byte array; Step S4: when the function is running, determine whether the CPU resource usage is higher than a preset value; if the result is yes, filter and mark the candidate functions, store the candidate functions in a constant-level array, and unload them; If the result is no, no processing is performed.

2. The function uninstallation method based on Java language runtime according to claim 1, characterized in that: In the step S1, the bytecode class file is loaded and read through the ClassReader class in the ASM framework; Determine whether the class name contains the prefix specified by the user; if the result is yes, convert the bytecode class file into a byte stream, that is, the filtered file; if the result is no, skip it and do not process it.

3. The function uninstallation method based on Java language runtime according to claim 2, characterized in that: In step S2, the ClassVisitor class is used to filter out user-defined functions according to the annotations; The annotations are determined according to a framework, i.e., a software toolset; The framework includes: a spring framework; The annotations include: @GetMapping, @PostMapping, and @PutMapping.

4. The function uninstallation method based on Java language runtime according to claim 3 is characterized in that: In step S3, the toByteArray method of the ClassWriter class is called to obtain a new byte array, and the new byte array is saved in a .class file; the .class file collects information when the Java program is running.

5. The function uninstallation method based on Java language runtime according to claim 4, characterized in that: In step S4, the preset value is set to 20%, and it is determined whether the CPU resource usage is higher than 20%; if the result is no, no processing is performed; If the result is yes and less than 50%, the candidate functions to be uninstalled are screened out and stored in a constant-level array to further determine whether the CPU resource usage is greater than or equal to 50%; If the result is yes, the candidate function is marked and uninstalled according to the uninstall rate set by the user; If the result is no, no processing will be done; The candidate functions include: the most recently executed user function or the function with the longest average running time.

6. A function unloading system based on Java language runtime, characterized in that: include: Information collection module: loads and reads bytecode class files, and filters them according to class names to obtain filtered files; According to the filtered file, filter and insert the user-defined function through annotation, convert the inserted user-defined function into a byte array, and convert the byte array into a new byte array; the new byte array is represented by the bytecode of the Java class; saving the new byte array; Function uninstallation policy module: When a function is running, it determines whether the CPU resource usage is higher than the preset value; if the result is yes, the candidate function is marked and uninstalled; if the result is no, no processing is performed.

7. The function unloading system based on Java language runtime according to claim 6, characterized in that: In the information collection module, the bytecode class file is loaded and read through the ClassReader class in the ASM framework; Determine whether the class name contains the prefix specified by the user; if the result is yes, convert the bytecode class file into a byte stream, that is, the filtered file; if the result is no, skip it and do not process it.

8. The function unloading system based on Java language runtime according to claim 7, characterized in that: In the information collection module, the ClassVisitor class is used to filter out user-defined functions according to annotations; The annotations are determined according to a framework, i.e., a software toolset; The framework includes: a spring framework; The annotations include: @GetMapping, @PostMapping, and @PutMapping.

9. The function unloading system based on Java language runtime according to claim 8, characterized in that: In the function uninstallation policy module, the toByteArray method of the ClassWriter class is called to obtain a new byte array.

10. The function unloading system based on Java language runtime according to claim 9, characterized in that: In the function uninstallation policy module, the new byte array is saved in a .class file; the .class file collects information when the Java program is running; Let the preset value be 20%, and determine whether the CPU resource usage is higher than 20%; If the result is no, no processing is performed; If the result is yes and less than 50%, the candidate functions to be uninstalled are screened out and stored in a constant-level array to further determine whether the CPU resource usage is greater than or equal to 50%; If the result is yes, the candidate function is marked and uninstalled according to the uninstall rate set by the user; If the result is no, no processing will be done; The candidate functions include: the most recently executed user function or the function with the longest average running time.

Images