Method and device for plug-in resource management, electronic device, computer readable medium

Abstract

The method for plug-in resource management provided in the embodiments of the present disclosure comprises the following steps: reading a bytecode file corresponding to the plug-in; and inserting monitoring bytecode at a resource consumption position of the bytecode file, wherein the resource consumption position is a position of bytecode corresponding to a resource function that needs to consume resources during running in the bytecode file, and the monitoring bytecode is used for identifying bytecode of the plug-in. The embodiments of the present disclosure further provide an apparatus for plug-in resource management, an electronic device and a computer readable medium.

Description

Technical Field

[0001] This disclosure relates to the field of resource management technology, and in particular to a method and apparatus for plug-in resource management, an electronic device, and a computer-readable medium. Background Technology

[0002] Existing basic software frameworks, such as the OSGi (Open Service Gateway Initiative) framework, are increasingly being used in various embedded devices, such as smart home gateways, set-top boxes, and other home networking devices.

[0003] By leveraging the OSGi framework's plug-in dynamic deployment technology, embedded devices enhance their ability to dynamically expand business capabilities.

[0004] However, if a plugin excessively requests or consumes virtual machine resources during operation, it may cause other plugins to fail to request resources, thus affecting the operation of other plugins. Summary of the Invention

[0005] This disclosure provides a method and apparatus for plug-in resource management, an electronic device, and a computer-readable medium.

[0006] In a first aspect, embodiments of this disclosure provide a method for managing plug-in resources, comprising:

[0007] Read the bytecode file corresponding to the plugin;

[0008] Monitoring bytecode is inserted at the resource consumption location of the bytecode file. The resource consumption location is the position of the bytecode corresponding to the resource function that needs to consume resources during operation in the bytecode file. The monitoring bytecode is used to identify the bytecode of the plugin.

[0009] In some embodiments, after inserting monitoring bytecode at the resource consumption location of the bytecode file, the method further includes: determining that the resources consumed by the resource function corresponding to the bytecode file are the resources consumed by the plugin.

[0010] In some embodiments, determining that the resources consumed by the resource function corresponding to the bytecode file are the resources consumed by the plugin includes: establishing a correspondence between the resource function and the plugin based on the monitored bytecode; determining the resource function corresponding to the plugin based on the correspondence, and determining that the resources consumed by the resource function corresponding to the plugin are the resources consumed by the plugin.

[0011] In some embodiments, the resource function includes a thread creation function for creating a plugin thread.

[0012] In some embodiments, determining the resources consumed by the resource function corresponding to the bytecode file as the resources consumed by the plugin includes: counting the CPU time occupied by the plugin threads created by the thread creation function corresponding to the bytecode file, and using the sum of the CPU time occupied by all the plugin threads as the CPU time occupied by the plugin; and / or, counting the number of plugin threads created by the thread creation function corresponding to the bytecode file, and using the number of plugin threads as the number of threads consumed by the plugin.

[0013] In some embodiments, the resource function includes an entry function, which includes a start function and a stop function.

[0014] In some embodiments, determining the resources consumed by the resource function corresponding to the bytecode file as the resources consumed by the plugin includes: calculating the memory space consumed by each plugin object, and using the sum of the memory spaces consumed by all the plugin objects as the memory space consumed by the plugin, wherein the plugin object is an object created during the execution of the start function and stop function corresponding to the bytecode file.

[0015] In some embodiments, after determining that the resources consumed by the resource function corresponding to the bytecode file are the resources consumed by the plugin, the method further includes: controlling the plugin based on the resources consumed by the plugin.

[0016] In some embodiments, the plugin is a plugin that runs based on the Open Services Gateway Protocol.

[0017] Secondly, embodiments of this disclosure provide an apparatus for managing plug-in resources, comprising:

[0018] The reading module is used to read the bytecode file corresponding to the plugin;

[0019] An insertion module is used to insert monitoring bytecode at the resource consumption location of the bytecode file. The resource consumption location is the position of the bytecode corresponding to the resource function that needs to consume resources during operation in the bytecode file. The monitoring bytecode is used to identify the bytecode of the plugin.

[0020] Thirdly, embodiments of this disclosure provide an electronic device, which includes:

[0021] One or more processors,

[0022] A memory that stores one or more programs, which, when executed by one or more processors, enable one or more processors to implement any of the above-mentioned plug-in resource management methods.

[0023] One or more I / O interfaces are connected between the processor and the memory to enable information exchange between the processor and the memory.

[0024] Fourthly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-described plug-in resource management methods.

[0025] In the plug-in resource management method, apparatus, electronic device, and computer-readable medium of this disclosure, monitoring bytecode is inserted at the resource consumption location of the bytecode file corresponding to the plug-in before the class corresponding to the plug-in is loaded. Through the monitoring bytecode, a correspondence between resource functions and plug-ins can be established during the class loading process. On the one hand, inserting monitoring bytecode before class loading and establishing the correspondence between resource functions and plug-ins during class loading has minimal impact on the original class loading process and is easy to implement. On the other hand, through the correspondence between resource functions and plug-ins, and the resources consumed by the resource functions, the resources consumed by each plug-in can be obtained, thereby achieving fine-grained control and management of resources and plug-ins, and improving the stability, reliability, and security of device operation. Attached Figure Description

[0026] In the accompanying drawings of the embodiments disclosed herein:

[0027] Figure 1 A flowchart illustrating a method for managing plug-in resources provided in this embodiment of the disclosure;

[0028] Figure 2 A flowchart illustrating another method for managing plug-in resources provided in this disclosure embodiment;

[0029] Figure 3 A flowchart illustrating another method for managing plug-in resources provided in this disclosure embodiment;

[0030] Figure 4 A flowchart illustrating another method for managing plug-in resources provided in this disclosure embodiment;

[0031] Figure 5 A flowchart illustrating another method for managing plug-in resources provided in this disclosure embodiment;

[0032] Figure 6 A flowchart illustrating another method for managing plug-in resources provided in this disclosure embodiment;

[0033] Figure 7 A block diagram illustrating the composition of a plug-in resource management apparatus provided in this disclosure embodiment;

[0034] Figure 8 A block diagram of an electronic device provided in an embodiment of this disclosure;

[0035] Figure 9 This is a block diagram illustrating the composition of a computer-readable medium provided in an embodiment of the present disclosure. Detailed Implementation

[0036] To enable those skilled in the art to better understand the technical solutions of the embodiments of this disclosure, the method and apparatus for plug-in resource management, electronic devices, and computer-readable media provided in the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0037] Embodiments of this disclosure will be described more fully below with reference to the accompanying drawings; however, the embodiments shown may be embodied in different forms and should not be construed as limited to the embodiments set forth in this disclosure. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will enable those skilled in the art to fully understand the scope of this disclosure.

[0038] The accompanying drawings of the embodiments of this disclosure are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain this disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings.

[0039] Embodiments of this disclosure can be described with reference to plan views and / or cross-sectional views, taking into account the ideal schematic diagrams of this disclosure. Therefore, the example illustrations may be modified according to manufacturing techniques and / or tolerances.

[0040] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0041] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. The term "and / or" as used in this disclosure includes any and all combinations of one or more of the associated enumerated entries. The singular forms "a" and "the" as used in this disclosure are also intended to include the plural forms unless the context clearly indicates otherwise. The terms "comprising," "made of," etc., as used in this disclosure specify the presence of the stated feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0042] Unless otherwise specified, all terms used in this disclosure (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this disclosure.

[0043] This disclosure is not limited to the embodiments shown in the accompanying drawings, but includes modifications to the configuration based on the manufacturing process. Therefore, the areas illustrated in the drawings are schematic, and the shapes of the areas shown illustrate specific shapes of the areas of an element, but are not intended to be limiting.

[0044] In some related technologies, multiple plugins deployed on a basic software framework (such as the OSGi framework) run on the same virtual machine (such as the Java Virtual Machine). The resources consumed by all plugins, such as threads, CPU (Central Processing Unit), and memory (such as Java heap, stack, and direct memory), depend on the resources of the virtual machine itself.

[0045] If a plugin requests excessive virtual machine resources or occupies virtual machine resources for an extended period during operation, it may affect the operation of other plugins. For example, if a plugin occupies the CPU for a long time, it may affect the operation of other plugins; if a plugin occupies memory for a long time, it may cause other plugins to fail to allocate memory, thus affecting the operation of other plugins.

[0046] In particular, if a plugin excessively requests or consumes virtual machine resources during operation, it can pose a significant security risk to the plugin's operation.

[0047] While statistical analysis of the resources consumed by the entire virtual machine can provide the total resource consumption of all plugins, enabling unified management of all plugins, it's impossible to analyze the individual resource consumption of each plugin. Therefore, it's also impossible to identify plugins that excessively request or consume virtual machine resources, and thus, fine-grained resource management is hindered.

[0048] Firstly, referring to Figure 1 This disclosure provides a method for managing plugin resources. This method can be used to manage the resources of each plugin among multiple plugins deployed on a basic software framework (such as the OSGi framework) and running on the same virtual machine (specifically, a Java Virtual Machine).

[0049] The plug-in resource management method of this disclosure embodiment may specifically include:

[0050] S101. Read the bytecode file corresponding to the plugin.

[0051] The device system reads all bytecode files corresponding to a certain plugin (i.e., a plugin that requires resource management).

[0052] Specifically, when the device system receives a class loading request for a class in the plugin, it reads all the bytecode files of that plugin from the plugin cache directory of the OSGi framework.

[0053] Class loading refers to the process during the runtime of a virtual machine where, when a class is needed, the bytecode file associated with that class is loaded into the virtual machine's memory, the bytecode file is run, and an object that the virtual machine can directly use is generated.

[0054] A class loading request is a request to load a specific class. A class loading request for a plugin is a request to load a class that is needed during the plugin's operation on the virtual machine (or during the plugin's operation).

[0055] Bytecode files, which are files with the ".class" extension, are object files generated by the Java compiler when compiling Java source files, which have the ".java" extension. During the compilation process of the Java compiler, a bytecode file is generated for each class in the Java source file.

[0056] The bytecode file corresponding to a plugin refers to the bytecode file of the class that the plugin needs to use during its operation on the virtual machine.

[0057] Therefore, when a class loading request for a class in a plugin is received, the bytecode files related to the class in that plugin will be loaded into the virtual machine memory (or cache). The bytecode file corresponding to the plugin can be easily obtained from the cache directory.

[0058] S102. Insert monitoring bytecode at the resource consumption location in the bytecode file. The resource consumption location is the position of the bytecode corresponding to the resource function that needs to consume resources during the operation in the bytecode file. The monitoring bytecode is used to identify the bytecode of the plugin.

[0059] The device system analyzes the read bytecode file to determine if there are any resource consumption locations. If so, it inserts monitoring bytecode at those locations.

[0060] The resource consumption location refers to the position of the bytecode corresponding to the resource function within the bytecode file. Resource-consuming functions are those functions that consume virtual machine resources during the execution of the virtual machine, or in other words, during the execution of a Java source file, such as thread creation functions.

[0061] Monitoring bytecode is used to identify the plugin corresponding to the bytecode file where resource consumption occurs; specifically, it can be the plugin's ID (unique code).

[0062] After the device system completes the insertion of the monitoring bytecode, it performs the class loading process according to the class loading request, that is, loads the corresponding bytecode file into the virtual machine memory and runs the bytecode file.

[0063] When the device system runs bytecode containing monitoring bytecode, a mapping between the plugin and the corresponding resource function in the inserted bytecode can be established based on the plugin identifier within the monitoring bytecode. Specifically, this can be achieved by creating a relationship table in the system to record the mapping between plugins and resource functions.

[0064] Since the resources consumed by resource functions during plugin operation are obtainable, the resources consumed by each plugin can be obtained relatively easily by understanding the correspondence between each plugin and a resource function, as well as the resources consumed by each resource function.

[0065] After obtaining the resources consumed by each plugin, on the one hand, when there are plugins that excessively request or occupy virtual machine resources, the plugins that excessively request or occupy virtual machine resources can be identified from multiple plugins based on the resources consumed by each plugin; on the other hand, by using plugins as the granularity, virtual machine resources can be controlled and managed in a finer way.

[0066] The plug-in resource management method of this disclosure inserts monitoring bytecode at the resource consumption location of the bytecode file corresponding to the plug-in before the class corresponding to the plug-in is loaded. Through the monitoring bytecode, a correspondence is established between resource functions and plug-ins during the class loading process. On the one hand, inserting monitoring bytecode before class loading and establishing the correspondence between resource functions and plug-ins during class loading has minimal impact on the original class loading process and is easy to implement. On the other hand, by using the correspondence between resource functions and plug-ins, and the resources consumed by the resource functions, the resources consumed by each plug-in can be obtained, thereby achieving fine-grained control and management of resources and plug-ins, improving the stability, reliability, and security of device operation.

[0067] In some embodiments, refer to Figure 2 After inserting monitoring bytecode at the resource consumption location of the bytecode file (S102), the following is also included:

[0068] S103. Determine that the resources consumed by the resource functions corresponding to the bytecode file are the resources consumed by the plugin.

[0069] After the device system completes the insertion of the monitoring bytecode, it performs the class loading process according to the class loading request, that is, loads the corresponding bytecode file into the virtual machine memory and runs the bytecode file.

[0070] When the bytecode containing the monitoring bytecode is run, the device system can identify the corresponding plugin for the resource function based on the plugin identifier in the monitoring bytecode. At the same time, since the resources consumed by the resource function during the plugin's operation are available, the resources consumed by the corresponding resource function can be used to determine the resources consumed by the plugin by running the bytecode containing the monitoring bytecode.

[0071] In some embodiments, refer to Figure 3 The resources consumed by the resource function corresponding to the bytecode file are determined to be the resources consumed by the plugin (S103), including:

[0072] S1031. Establish the correspondence between resource functions and plugins based on the monitoring bytecode.

[0073] S1032. Based on the correspondence, determine the resource function corresponding to the plugin, and determine that the resources consumed by the resource function corresponding to the plugin are the resources consumed by the plugin.

[0074] After the device system completes the insertion of the monitoring bytecode, it performs the class loading process according to the class loading request, that is, loads the corresponding bytecode file into the virtual machine memory and runs the bytecode file.

[0075] When the device system runs the bytecode with the inserted monitoring bytecode, the correspondence between the plugin and the resource function corresponding to the bytecode with the inserted monitoring bytecode can be established based on the plugin identifier in the monitoring bytecode.

[0076] Specifically, this could involve creating a relationship table in the system to record the correspondence between plugins and resource functions.

[0077] Since the resources consumed by resource functions during plugin operation are obtainable, the resources consumed by each plugin can be obtained relatively easily by understanding the correspondence between each plugin and a resource function, as well as the resources consumed by each resource function.

[0078] After obtaining the resources consumed by each plugin, on the one hand, when there are plugins that excessively request or occupy virtual machine resources, the plugins that excessively request or occupy virtual machine resources can be identified from multiple plugins based on the resources consumed by each plugin; on the other hand, by using plugins as the granularity, virtual machine resources can be controlled and managed in a finer way.

[0079] In some embodiments, the resource function includes a thread creation function, which is used to create a plugin thread.

[0080] In some embodiments, refer to Figure 4 The resources consumed by the resource function corresponding to the bytecode file are determined to be the resources consumed by the plugin (S103), including:

[0081] S1033. The CPU time occupied by the plugin threads created by the thread creation function corresponding to the bytecode file is counted, and the sum of the CPU time occupied by all plugin threads is taken as the CPU time occupied by the plugin.

[0082] And / or,

[0083] S1034. Count the number of plugin threads created by the thread creation function corresponding to the bytecode file, and use the number of plugin threads as the number of threads consumed by the plugin.

[0084] When the bytecode corresponding to the thread creation function is executed, the device system can determine the correspondence between the plugin and the thread created by the thread creation function based on the plugin identifier in the monitored bytecode.

[0085] Among them, the thread creation function (or thread constructor) is a function used to create threads. There are multiple ways to create threads, such as creating threads by extending the thread class.

[0086] A thread is the unit of execution for a plugin. Each thread has an ID that is different from other threads. Multiple threads form a process, and the multiple threads in a process share all the resources of that process.

[0087] Determine the correspondence between the plugin and the thread created by the thread creation function. Specifically, this can be done by establishing a correspondence between the plugin thread ID and the plugin ID.

[0088] During the operation of a plugin, the threads and the resources consumed by those threads are available. Therefore, by understanding the correspondence between each plugin and its threads, and the resources consumed by each thread, it is relatively easy to obtain the resources consumed by each plugin.

[0089] Specifically, after creating the mapping between plugins and threads, the device system calculates the CPU time occupied by a plugin by counting the CPU time used by all threads corresponding to that plugin. More specifically, the sum of the CPU time used by all threads corresponding to a plugin can be used as the CPU time occupied by that plugin.

[0090] After establishing the correspondence between plugins and threads, the device system obtains the number of threads consumed by a plugin by counting the total number of threads corresponding to that plugin.

[0091] In some embodiments, the resource function includes an entry function, which includes a start function and a stop function.

[0092] In some embodiments, refer to Figure 5 The resources consumed by the resource function corresponding to the bytecode file are determined to be the resources consumed by the plugin (S103), including:

[0093] S1035. Calculate the memory space consumed by each plugin object, and use the sum of the memory space consumed by all plugin objects as the memory space consumed by the plugin. The plugin object is the object created during the execution of the start function and stop function corresponding to the bytecode file.

[0094] When the bytecode corresponding to the start and stop functions of the device system is run, the system establishes a correspondence between plugins and plugin objects based on the plugin identifier in the monitoring bytecode.

[0095] Each plugin has only one startup function to begin its execution and one stop function to end it. During the execution from the start of the startup function to the end of the stop function, all objects created are plugin objects.

[0096] Therefore, when inserting monitoring bytecode into the bytecode corresponding to the start and stop functions, the monitoring bytecode needs to be inserted at the positions in the bytecode file corresponding to the start and end of the start and stop functions, so as to monitor all plugin objects created by the plugin from the start to the end of its operation and establish the correspondence between plugin objects and plugins.

[0097] After creating the mapping between plugins and plugin objects, the device system calculates the memory consumption of a plugin by summing the memory space consumed by all plugin objects corresponding to that plugin. Specifically, the sum of the memory space consumed by all plugin objects corresponding to a plugin can be used as the memory consumption of that plugin.

[0098] In some embodiments, refer to Figure 6 After determining that the resources consumed by the resource function corresponding to the bytecode file are the resources consumed by the plugin (S103), the following steps are also included:

[0099] S104. Control the plugin based on the resources it consumes.

[0100] Based on the resources consumed by the resource functions (such as threads, CPU time, memory space, etc.), the resources consumed by each plugin are calculated, and all plugins are controlled according to the resources consumed by each plugin.

[0101] Specifically, controlling the plugin can be done in the following ways:

[0102] Based on the resources that a plugin may consume during its operation, the resource consumption risk level of each plugin is calculated. If a plugin may consume a large amount of resources during its operation, the resource consumption risk level of that plugin is high; conversely, if a plugin may consume a small amount of resources during its operation, the resource consumption risk level of that plugin is low.

[0103] Specifically, plugins can be categorized according to their type, such as system plugins (plugins used by the OSGi framework), pre-installed plugins (plugins necessary for device services), and open plugins (plugins that may be needed for device services). A plugin category file is generated, which records the category information of each plugin, such as plugin name, plugin version number, plugin type (one of system plugin, pre-installed plugin, or open plugin), as well as the plugin's resource consumption risk level and plugin function description.

[0104] During plugin operation, the plugin classification information in the plugin classification file is read, and plugins with high and medium risk levels of resource consumption are identified as key monitoring targets. They are then controlled using Linux (an operating system) security control technology, such as Cgroup (Control Groups) technology.

[0105] Specifically, controlling the plugin can also be done in the following ways:

[0106] Set resource consumption thresholds for individual plugins, such as thresholds for CPU time, memory consumption, and number of threads consumed by a plugin. If a plugin consumes more resources than the set thresholds, then control measures will be implemented for that plugin.

[0107] Specifically, you can set the threshold for CPU time consumed by the plugin by setting Bundle.Resource.CPU.Threshold in the resource consumption configuration file; you can set the threshold for memory consumed by the plugin by setting Bundle.Resource.Memory.Threshold in the resource consumption configuration file; and you can set the threshold for the number of threads consumed by the plugin by setting Bundle.Resource.Thread.Threshold in the resource consumption configuration file.

[0108] During plugin operation, the system reads the thresholds set in the resource consumption configuration file and uses these thresholds to determine whether to control the plugin. If a plugin's resource consumption exceeds the set threshold, Linux security control technology will be used to control the plugin.

[0109] Specifically, controlling plugins can also include:

[0110] The resource consumption value of each plugin is calculated and stored in the plugin resource consumption table. Based on the data corresponding to each plugin in the plugin resource consumption table, the historical average value of each type of resource consumed by each plugin under the Java Virtual Machine is calculated, and the calculated historical average value is used as the basis for controlling the plugin.

[0111] In some embodiments, the plugin is a plugin that runs based on the Open Services Gateway Protocol.

[0112] The basic software framework of this disclosure embodiment may specifically be the OSGi framework.

[0113] When deploying plugins, the OSGi framework uses dynamic plugin deployment technology, which is lightweight and flexible compared to traditional static plugin deployment technology.

[0114] Based on the OSGi framework, the method of this disclosure embodiment may specifically include:

[0115] A01. Before the Java Virtual Machine starts loading the class corresponding to the plugin, the JavaAgent class library intercepts the class loading process and retrieves the bytecode file corresponding to the plugin from the cache directory.

[0116] A02. Analyze and edit the obtained bytecode files using the JavaSsist library.

[0117] Using JavaSsist, the bytecode in the bytecode file is analyzed to determine whether the function corresponding to the bytecode is the plugin's start or stop function. If so, a monitoring bytecode word, specifically the plugin ID, is inserted at the corresponding positions in the bytecode file at the beginning and end of the plugin's start or stop function. Simultaneously, it is determined whether the function corresponding to the bytecode is a thread creation function. If so, a monitoring bytecode word, specifically the plugin ID, is inserted at the corresponding position in the bytecode file.

[0118] A03. During the class loading process, the bytecode file containing the monitoring bytecode is run. Based on the monitoring bytecode, a table is established inside the Java Virtual Machine to record the correspondence between plugins and threads.

[0119] The system calculates and tracks the resource consumption of plugins by defining the Java extension class Javax.Bundle.ResourceInfo and the JNI (Java Native Interface). It also provides interfaces for obtaining the calculated plugin resource consumption by defining the Javax.Bundle.CPUUsage class, such as the getBundleID function (for obtaining the plugin ID) and the getCPUTime function (for obtaining the CPU time used by the plugin).

[0120] The method for calculating the CPU time occupied by the plugin is as follows: when all threads of the Java Virtual Machine start, the start time of the thread is set. When it is necessary to calculate the CPU time occupied by the plugin, all currently running threads are obtained through the JNI of the Java Virtual Machine. The difference between the most recent CPU time occupied by each running thread and its start time is calculated to obtain the CPU time occupied by that thread. The CPU time occupied by the thread corresponding to the plugin among the running threads is accumulated to obtain the CPU time occupied by the plugin.

[0121] A04. Obtain data on the resources consumed by the plugin by calling the interface, process the obtained data and record it in the device's internal log file, or print it to the interface.

[0122] Based on the OSGi framework, step S104 of the plugin resource management method in this embodiment of the disclosure, namely controlling the plugin according to the resources consumed by the plugin, may further include:

[0123] B01. Obtain the plugins running under the OSGi framework by calling the OSGi service interface to get the name of the running plugin.

[0124] BO2. Based on the plugin classification file, determine the resource consumption risk level of each plugin in turn. If a plugin has a high or medium risk level of resource consumption, it is necessary to implement fine-grained control over that plugin.

[0125] B03. Periodically update the resource consumption data of plugins that require fine-grained control, calculate the CPU time occupied by the plugin in each cycle under the Java Virtual Machine, and determine whether the CPU time occupied by the plugin exceeds the set threshold for a continuous period of T (specifically 5) cycles.

[0126] B04, if so, then based on the correspondence between plugins and threads, obtain all running threads corresponding to that plugin, and set the IDs of these threads as control parameters to limit the CPU time occupied by these threads during execution.

[0127] Secondly, referring to Figure 7 This disclosure provides an apparatus for managing plug-in resources, comprising:

[0128] The reading module is used to read the bytecode file corresponding to the plugin;

[0129] The insertion module is used to insert monitoring bytecode at the resource consumption location in the bytecode file. The resource consumption location is the position of the bytecode corresponding to the resource function that needs to consume resources during the operation in the bytecode file. The monitoring bytecode is used to identify the bytecode of the plugin.

[0130] In the plug-in resource management apparatus of this disclosure, before the class corresponding to the plug-in is loaded, monitoring bytecode is inserted at the resource consumption location of the bytecode file corresponding to the plug-in. Through the monitoring bytecode, a correspondence is established between resource functions and plug-ins during the class loading process. On the one hand, inserting monitoring bytecode before class loading and establishing the correspondence between resource functions and plug-ins during class loading has minimal impact on the original class loading process and is easy to implement. On the other hand, by using the correspondence between resource functions and plug-ins, and the resources consumed by the resource functions, the resources consumed by each plug-in can be obtained, thereby achieving fine-grained control and management of resources and plug-ins, and improving the stability, reliability, and security of device operation.

[0131] Thirdly, referring to Figure 8 This disclosure provides an electronic device, which includes:

[0132] One or more processors,

[0133] A memory that stores one or more programs, which, when executed by one or more processors, enable one or more processors to implement any of the above-mentioned plug-in resource management methods.

[0134] One or more I / O interfaces are connected between the processor and the memory to enable information exchange between the processor and the memory.

[0135] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory to realize information interaction between the memory and the processor, including but not limited to the data bus (Bus).

[0136] Fourthly, refer to Figure 9 This disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-described plug-in resource management methods.

[0137] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, enabling information exchange between the memory and the processor, including but not limited to the data bus (Bus).

[0138] Those skilled in the art will understand that all or some of the steps, systems, and devices disclosed above, as functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0139] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be executed by several physical components working together.

[0140] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; read-only optical disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cartridges, magnetic tapes, disk storage or other magnetic storage; and any other media that can be used to store desired information and can be accessed by a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0141] This disclosure has disclosed exemplary embodiments, and although specific terminology has been used, it is for general illustrative purposes only and should not be construed as limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A method for managing plugin resources, comprising: Read the bytecode file corresponding to the plugin; The plugin is a dynamically deployed plugin based on the basic software framework; Monitoring bytecode is inserted at the resource consumption location of the bytecode file. The resource consumption location is the position of the bytecode corresponding to the resource function that needs to consume resources during the operation in the bytecode file. The monitoring bytecode is used to identify the bytecode of the plugin. The resource function includes a thread creation function, which is used to create a plugin thread. Establish the correspondence between the resource functions and the plugins based on the monitoring bytecode; Based on the correspondence, the resource function corresponding to the plugin is determined, and the resources consumed by the resource function corresponding to the plugin are determined to be the resources consumed by the plugin. Based on the resources consumed by the plugins, each plugin among the multiple plugins deployed in the basic software framework is dynamically managed using Linux security control technology.

2. The method according to claim 1, wherein, The step of determining that the resources consumed by the resource function corresponding to the bytecode file are the resources consumed by the plugin includes: The CPU time occupied by the plugin threads created by the thread creation function corresponding to the bytecode file is counted, and the sum of the CPU time occupied by all the plugin threads is taken as the CPU time occupied by the plugin. And / or, The number of plugin threads created by the thread creation function corresponding to the bytecode file is counted, and the number of plugin threads is used as the number of threads consumed by the plugin.

3. The method according to claim 1, wherein, The resource function includes an entry function, which in turn includes a start function and a stop function.

4. The method according to claim 3, wherein, The step of determining that the resources consumed by the resource function corresponding to the bytecode file are the resources consumed by the plugin includes: The memory space consumed by each plugin object is calculated, and the sum of the memory space consumed by all the plugin objects is taken as the memory space consumed by the plugin. The plugin object is an object created during the execution of the start function and stop function corresponding to the bytecode file.

5. The method according to claim 1, wherein, The plugin is a plugin that runs based on the Open Services Gateway Protocol.

6. The method according to claim 1, wherein, The dynamic management of each plugin among the multiple plugins deployed in the basic software framework includes: During plugin operation, the plugin classification information in the plugin classification file is read, and plugins with high and medium risk levels of resource consumption in the classification information are identified as key monitoring targets. The key monitoring targets are controlled using Linux security control technology; The plugin classification file records the classification information of each plugin, the resource consumption risk level of the plugin, and the plugin function description; and the resource consumption risk level of the plugin is determined based on the resources that the plugin may consume during operation.

7. The method according to claim 1, wherein, The dynamic management of each plugin among the multiple plugins deployed in the basic software framework includes: The resource consumption thresholds for individual plugins are set through a resource consumption configuration file. These thresholds include the thresholds for CPU time occupied by the plugin, memory consumption, and the number of threads consumed. During the operation of the plugin, the threshold set in the resource consumption configuration file is read. When the resources consumed by the plugin exceed the set threshold, the plugin is controlled through Linux security control technology.

8. The method according to claim 1, wherein, The dynamic management of each plugin among the multiple plugins deployed in the basic software framework includes: calculating the resource consumption value of each plugin and storing it in the plugin resource consumption table; calculating the historical average value of each type of resource consumed by each plugin under the JAVA virtual machine based on the data corresponding to each plugin in the plugin resource consumption table; and using the calculated historical average value as the basis for controlling the plugin.

9. An apparatus for managing plug-in resources, comprising: The reading module is used to read the bytecode file corresponding to the plugin; An insertion module is used to insert monitoring bytecode at the resource consumption location of the bytecode file. The resource consumption location is the position of the bytecode corresponding to the resource function that needs to consume resources during operation in the bytecode file. The monitoring bytecode is used to identify the bytecode of the plugin. A correspondence between the resource function and the plugin is established based on the monitoring bytecode. Based on the correspondence, the resource function corresponding to the plugin is determined, and the resources consumed by the resource function corresponding to the plugin are determined to be the resources consumed by the plugin. Based on the resources consumed by the plugin, each plugin among multiple plugins deployed in the basic software framework is dynamically managed using Linux security control technology. The resource function includes a thread creation function, which is used to create plugin threads.

10. An electronic device comprising: One or more processors; A memory having stored one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the plug-in resource management method according to any one of claims 1 to 8; One or more I / O interfaces are connected between the processor and the memory to enable information exchange between the processor and the memory.

11. A computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method for managing plug-in resources according to any one of claims 1 to 8.

Images