Deterministic memory allocation for real-time applications

Abstract

A method system and non-transitory computer-readable medium for deterministic memory allocation for real-time applications is provided. [Solution] The method includes a step 210 of receiving bitcode representing compiled source code of an application, the bitcode including an allocation function for allocating memory that calls a dummy function using one or more parameters; a step 220 of automatically scanning the bitcode to detect each call to the dummy function in the bitcode; a step 260 of extracting, for each detected call to the dummy function, one or more parameters used in the detected call to the dummy function, and generating an allocation record from the extracted one or more parameters; and a step 260 of generating a header file based on the generated allocation record.

Description

Technical Field

[0001] The embodiments described in this specification are generally directed to real-time applications, and more particularly, to deterministic memory allocation in real-time safety-critical applications (e.g., autonomous movement of vehicles and robots).

Background Art

[0002] Memory allocation in a real-time safety-critical environment should be safe and provable. <​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ [Overview of the project]

[0005] Therefore, for deterministic memory allocation in real-time applications A system, method, and non-temporary computer-readable medium are disclosed. In one embodiment, A method has been developed that involves using at least one hardware processor to perform the following: It will be shown.

[0006] Scan the bitcode representing the compiled source code of the application. The step is to call a dummy function that uses multiple parameters in the source code. It includes an allocation function for allocating memory to be used, and the multiple parameters are memory The application includes the identifier of the memory pool and the size of the data type to be stored in the memory pool. The steps include scanning the bitcode representing the compiled source code of the program, While scanning the bitcode, each call to the dummy function within the bitcode Steps to detect an outflow, and for each call to the dummy function, the dummy function Extract the multiple parameters used in the detected call to, and extract From the multiple parameters, the identifier and the data type of the memory pool are selected. The steps include generating an assignment record that includes and and the generated assignment record The steps include generating an assignment record list and, based on the assignment record list... The step of generating a header file, wherein the header file is one or more buckets The definition of a set and the definition of one or more memory pools, and the one or more memory pools Each definition identifies at least one of the one or more buckets, the allocation This includes the step of generating a header file based on the record list.

[0007] This method uses the at least one hardware processor, Before the step of scanning the bitcode, the source code of the bitcode The steps to compile and After the step of generating the header file, the source code in the header file This could further include a recompile step.

[0008] Each of the definitions of the one or more buckets may include the number of blocks and the block size. Yes, it is possible. The step of generating the header file is performed by each of the assignment record lists For a unique size, a small number of buckets containing block sizes that match that unique size. It can include generating at least one definition. The pp has, for each unique identifier in the assignment record list, that identifier The step may further include generating the definition of the memory pool. The definition is associated with the identifier of that memory pool in the allocation record list. For each unique size, the block size is one or more of the block sizes that match that size. It may contain a reference to one of the definitions of the ket. A block that matches its size. The step of generating at least one definition of a bucket that includes its size matches that size. The step may include generating a bucket definition that includes the block size.

[0009] Each of the above definitions of one or more memory pools may include a tuple, includes one or more references, and each of the one or more references identifies one of the one or more buckets. Identify one of them.

[0010] In the bitcode, each instance of the allocation function may be bound to the single memory pool such that the allocation function cannot be allocated from any memory pool other than the single memory pool. While the memory pool is undefined, the application may allocate memory from available upstream resources, and while the memory pool is defined, it may be configured to allocate memory from the memory pool. It may be bound to the single memory pool.

[0011] While the memory pool is undefined, the application allocates memory from available upstream resources, and while the memory pool is defined, it is configured to allocate memory from the memory pool. While the memory pool is undefined, the application allocates memory from available upstream resources, and while the memory pool is defined, it is configured to allocate memory from the memory pool. It may be configured to allocate memory from the memory pool.

[0012] The source code may be written in the C++ programming language. The allocation function may be a custom allocator according to the allocator model of the C++ programming language. The allocation function may be a custom allocator according to the allocator model of the C++ programming language. It may be.

[0013] The method may further include using the at least one hardware processor to generate a call graph representing the path of function calls from the entry point of the application to the allocation function for each of the one or more allocations. For each of the one or more allocations, the method may further include using the at least one hardware processor to generate a call graph representing the path of function calls from the entry point of the application to the allocation function. It can further include the step of generating a call graph representing the path of function calls from the entry point of the application to the allocation function for each of the one or more allocations. It can be.

[0014] The plurality of parameters may further include an identifier of the data type to be stored in the memory pool. It may further include.

[0015] The method can be implemented by an executable software module of a processor-based system such as a server and / or executable instructions stored in a non-transitory computer-readable medium. The method can be implemented by an executable software module of a processor-based system such as a server and / or executable instructions stored in a non-transitory computer-readable medium. It can be implemented. [Brief explanation of the drawing]

[0016] Details of the present invention relate to both its structure and operation, and similar parts are given the same reference number. This can be partially obtained by studying the attached drawings. [Figure 1] Figure 1 shows an example of a processing system according to one embodiment, in which one or more of the processes described herein can be performed. [Figure 2] Figure 2 shows an example of source code for an allocator template according to one embodiment. [Figure 3] Figure 3 shows the source code for an example implementation of buckets in a memory pool according to one embodiment. [Figure 4] Figure 4 shows the source code of an example implementation of a bucket constructor and destructor function according to one embodiment. [Figure 5] Figure 5 shows the source code of an example implementation of an allocation function that allocates blocks within a bucket, according to one embodiment. [Figure 6] Figure 6 shows the source code of an example implementation of a release function that releases blocks within a bucket, according to one embodiment. [Figure 7] Figure 7 shows source code for an example implementation of a template structure that defines a memory pool, according to one embodiment. [Figure 8] Figure 8 shows source code for an implementation example that specializes a template structure defining a memory pool for a specific application example, according to one embodiment. [Figure 9] Figure 9 shows the source code of an example implementation of several structures that define the characteristics of a memory pool according to one embodiment. [Figure 10] Figure 10 shows the source code of an example implementation of a memory pool creation function according to one embodiment. [Figure 11] Figure 11 shows the source code of an example implementation of memory pool initialization according to one embodiment. [Figure 12]Figure 12 shows the source code of an example implementation of an assignment function that utilizes a first-fit strategy according to one embodiment. [Figure 13] Figure 13 shows the source code of an example implementation of an info structure to assist in bucket selection, according to one embodiment. [Figure 14] Figure 14 shows the source code of an example implementation of an allocation function for allocating buckets in a memory pool, according to one embodiment. [Figure 15] Figure 15 shows the source code of an example implementation of a release function for freeing buckets in a memory pool, according to one embodiment. [Figure 16] Figure 16 shows an example usage scenario in which the same memory pool is used for nested data objects according to one embodiment. [Figure 17] Figure 17 shows an example usage scenario in which separate memory pools are used for nested data objects according to one embodiment. [Figure 18] Figure 18 shows the source code of an example implementation of a static pool allocator according to one embodiment. [Figure 19] Figure 19 shows the source code of an example implementation of a static pool allocator allocation function according to one embodiment. [Figure 20] Figure 20 shows the source code of an example implementation of an instrument namespace that defines a dummy function, according to one embodiment. [Figure 21] Figure 21 shows the source code of an example of an instrument code injection into the allocation function of a static pool allocator according to one embodiment. [Figure 22] Figure 22 shows the source code of an example implementation of a static pool allocator release function according to one embodiment. [Figure 23] Figure 23 shows the source code of an example implementation of a path for analyzing bitcode according to one embodiment. [Figure 24] Figure 24 shows the source code for a simple application using one embodiment of a static pool allocator. [Figure 25] Figure 25 shows a call graph for allocation generated by a simple application path according to one embodiment. [Figure 26] Figure 26 shows an example of a header file according to one embodiment. [Figure 27] Figure 27 shows an example of a process for optimizing the memory pool used by an application, according to one embodiment. [Modes for carrying out the invention]

[0017] In one embodiment, for example, in applications where real-time and / or security is critical... A system, method, and non-temporary control for deterministic memory allocation for use in A computer-readable medium is disclosed. After reading this description, a person skilled in the art will be able to see various alternative implementations. Methods for implementing the present invention in both conventional and alternative applications will become clear. However, although various embodiments of the present invention have been described herein, these embodiments It should be understood that these are presented for illustrative purposes only and are not limiting. This detailed description of various embodiments is provided for in accordance with the attached claims. This should not be interpreted as limiting the scope or breadth of the invention.

[0018] (1. System Overview) Figure 1 shows an exemplary wired or This is a block diagram of wireless system 100. For example, system 100 is as shown herein. Explain (for example, store one or more software modules such as optimization tools and As one or more functions, processes, or methods (for performing / or execution), or those It can be used in conjunction with the server or any conventional part. A sonar computer, or any other processor capable of wired or wireless data communication. It may be a compatible device. As will be obvious to those skilled in the art, other computer systems and / or Alternatively, you can use an architecture.

[0019] System 100 preferably includes one or more processors, such as processor 110. Auxiliary processors that manage input / output, and auxiliary processors that perform floating-point mathematical operations. , a special-purpose microcontroller with an architecture suitable for high-speed execution of signal processing algorithms A processor (e.g., a digital signal processor), a slave processor subordinate to the main processing system. Processor (e.g., backend processor), dual or multiprocessor system Additional microprocessors or controllers, and / or coprocessors for the system. An additional processor may be provided. Such an auxiliary processor is a separate processor. It may be a separate unit, or it may be integrated with processor 110. Used with system 100. Examples of possible processors include, but are not limited to, the "Pentium®" processor. This includes "Core i7" processors and "Xeon®" processors. These are all available from Intel Corporation in Santa Clara, California.

[0020] The processor 110 is preferably connected to the communication bus 105. The communication bus 105 is A data channel to facilitate information transfer between the storage device of system 100 and other peripheral components. Channels may also be included. Furthermore, the communication bus 105 includes a data bus, an address bus, and / or a signal set used for communication with the processor 110, including a control bus (not shown). A set may be provided. The communication bus 105 is, for example, an industry standard architecture (ISA). Extended Industry Standard Architecture (EISA), Microchannel Architecture (MCA) ), Peripheral Components Interconnection (PCI) Local Bus, "IEEE488" General Purpose Interface Bus (GPIB), "IEEE696 / S-100", and / or similar. Any standard or non-standard batteries, such as standards popularized by the Institute of Electrical and Electronics Engineers (IEEE) It may be composed of a S architecture.

[0021] System 100 preferably includes a main memory 115 and a secondary memory 120. That is also acceptable. The main memory 115 is one of the functions and / or modules discussed herein. Instructions and data for a program running on processor 110, such as one or more of the following. It provides a memory device. The program stored in memory is executed by the processor 110. Ram is not limited to "C / C++", "Java", "JavaScript", Any appropriate word including "Perl", "Visual Basic", ".NET", etc. It should be understood that it can be written and / or compiled according to the word. Memory 115 is typically dynamic random access memory (DRAM) and / or It is a semiconductor-based memory such as static random access memory (SRAM). Examples of conductor-based memory types include "SDRAM (synchronous dy ``namic random access memory)'', ``RDRAM (Ramb us dynamic random access memory)", "FRAM( (ferroelectric random access memory) and others It includes "ROM (read-only memory)".

[0022] The secondary memory 120 optionally includes an internal medium 125 and / or a removable medium 130. It may include: The removable medium 130 is read by any well-known method and / or or is written. The removable storage medium 130 is, for example, a magnetic tape drive, Compact disc (CD) drives, digital multi-purpose disc (DVD) drives, and other optical drives. This may be a hard drive, a flash memory drive, and / or something of the same kind.

[0023] Secondary memory 120 contains computer executable code (for example, open Non-temporary computers containing the indicated software module and / or other data It is a readable medium. Computer software stored in secondary memory 120 and The data is loaded into main memory 115 for execution by processor 110.

[0024] In another embodiment, the secondary memory 120 also contains computer programs or other data. This includes other similar means for enabling the loading of instructions into system 100. However, that is also acceptable. Such means include, for example, software and data on an external storage medium 145 It may also include a communication interface 140 that allows transfer from to system 100. Examples of external storage media 145 include external hard disk drives, external optical drives, and external This may include a magneto-optical drive and / or similar devices. Other examples of secondary memory 120 This is "PROM (programmable read-only memory)", "EPROM(erasable programmable read-only m "EEPROM(electrically erasable re (Ad-only memory), and flash memory (similar to EEPROM) It could be a semiconductor-based memory such as lock-oriented memory.

[0025] As described above, system 100 may include a communication interface 140. Interface 140 connects system 100 to external devices (e.g., printers) and networks. It enables the transfer of software and data between or to other information sources. For example, computer software or executable code communicates via interface 140 From the network server (e.g., platform 110) to system 100 via It may be forwarded. An example of a communication interface 140 is a built-in network adapter. Network interface card (NIC), personal computer memory card International Network Center Network Association (PCMCIA) network cards, CardBus network adapters, wireless Network adapter, Universal Serial Bus (USB) network adapter, Dem, wireless data card, communication port, infrared interface, "IEEE1394" A wire interface connects System 100 to a network or another computer device. Other optional devices that can be connected are also included. The communication interface 140 is preferably This includes Ethernet "IEEE 802" standard, Fibre Channel, and Digital Subscriber Line (DS). L), Asynchronous Digital Subscriber Line (ADSL), Frame Relay, Asynchronous Transfer Mode (AT M), Integrated Digital Services Network (ISDN), Personal Communication Services (PCS), Transmission control protocol / Internet protocol (TCP / IP), serial line input Internet Protocol / Point Protocol (SLIP / PPP) and other industry-known protocols It implements the COLL standard, but uses customized or non-standard interface protocols. It is acceptable to implement it.

[0026] The software and data transferred via the communication interface 140 are generally: These are telecommunication signals 155 in form. These signals 155 are transmitted via the communication channel 150. It may be provided to the communication interface 140. In one embodiment, the communication channel 150 This may be a wired or wireless network, or any other type of communication link. The communication channel 150 carries the signal 155, and to give a few examples, it is transmitted via a wire or cable. Cable, fiber optic, conventional telephone line, cellular telephone link, wireless data communication link, Various wired or wireless communications, including linear frequency ("RF") links or infrared links. It can be implemented using various means.

[0027] Computer executable code (for example, code consisting of one or more software modules) The computer program is stored in the main memory 115 and / or the secondary memory 120. The computer executable code is received via the communication interface 140, and the main It is also possible to store it in memory 115 and / or secondary memory 120. When the computer executable code is executed, system 100 will be as described elsewhere in this specification. The various functions of the disclosed embodiments described can be performed.

[0028] In this specification, the term "computer-readable medium" refers to computer executable code. and / or other data to be provided to system 100 or within system 100 It is used to refer to any non-temporary computer-readable storage medium used. Examples of such media include main memory 115, secondary memory 120 (internal memory 125, removable (including the available media 130 and the external storage medium 145), and the communication interface 140 Any peripheral device (network information server or other network) that is connected to it in a communicative manner (network information server or other network Examples include workpieces. These non-temporary computer-readable media are executable. The system can use code, programming instructions, software, and / or other data. This is a means to provide 100.

[0029] In embodiments implemented using software, the software is a computer-readable medium A removable medium 130 is housed in the body, and an input / output (I / O) interface 135 is located within it. Alternatively, it can be loaded into system 100 via communication interface 140. In such an embodiment, the software sends a telecommunications signal 155 to the system 100. The software is loaded. When the software is executed by the processor 110, preferably The processor 110 has one of the processes and functions described elsewhere in this specification. Perform one or more actions.

[0030] In this embodiment, the input / output interface 135 is one or more of the system 100 Provides an interface between a component and one or more input and / or output devices. Examples of devices include, but are not limited to, sensors, keyboards, touchscreens, or other touch devices. Chi-sensitive devices, biosensing devices, computer mice, trackballs, pen-type devices Including input devices and / or similar devices. Examples of output devices include, but are not limited to, However, other processing equipment, cathode ray tubes (CRTs), plasma displays, light-emitting diodes ( LED displays, liquid crystal displays (LCDs), printers, vacuum fluorescent displays (VFD), Surface Conductive Electron Emitter Display (SED), Field Emission Display (F Examples include ED), and / or similar devices. In some cases, touch panel displays. When playing (for example, on a smartphone, tablet, or other mobile device), Input and output devices are sometimes combined.

[0031] System 100 wirelessly transmits data over a voice network and / or data network. It may also include any wireless communication components that facilitate communication. Wireless communication components include antennas. The system includes a stem 170, a wireless system 165, and a baseband system 160. In M100, radio frequency (RF) signals are controlled by the radio system 165, and the antenna It is transmitted and received in the air by the NA System 170.

[0032] In one embodiment, the antenna system 170 includes one or more antennas and an antenna system One or more switches that perform a switching function to provide transmit and receive signal paths to stem 170. This may include the above multiplexer (not shown). In the receiving path, the received RF signal is multi The lutiplexer amplifies the received RF signal and transmits the amplified signal to the wireless system 165. It can be coupled to a low-noise amplifier (not shown).

[0033] In another embodiment, the wireless system 165 is configured to communicate at various frequencies. It may include one or more wireless devices. In one embodiment, the wireless system 165 is ...combining a demodulator (not shown) and a modulator (not shown) into a single integrated circuit (IC). It is possible. Also, the demodulator and modulator may be separate components. The demodulator then strips off the RF carrier signal, leaving the baseband received audio signal. This is transmitted from the wireless system 165 to the baseband system 160.

[0034] If the received signal contains voice information, the baseband system 160 will transmit that signal It decodes the signal and converts it to an analog signal. Then, it amplifies the signal and sends it to the speaker. Also, The baseband system 160 receives analog audio signals from the microphone. These analog audio signals are then converted to digital signals by the baseband system 160. It is converted to a number and encoded. The baseband system 160 also uses digital for transmission. The baseband transmission signal is encoded and routed to the modulator portion of the wireless system 165. It generates an audio signal. The modulator transmits the baseband audio signal as an RF carrier signal. It is mixed with and routed to the antenna system 170 and passes through a power amplifier (not shown). It generates an RF transmission signal that can be used. The power amplifier amplifies the RF transmission signal and turns it into an amplifier. The signal is routed to the Tena System 170, where it is switched to the antenna port for transmission. It can be done.

[0035] The baseband system 160 may also be a central processing unit (CPU). It is coupled to the sub-processor 110 in a communicative manner. The processor 110 has a data storage area 115 It can access and 120. The processor 110 preferably has access to main memory 1 Instructions that can be stored in 15 or secondary memory 120 (i.e., disclosed software) A computer is configured to run computer programs (such as software). The program is received from the baseband processor 160 and stored in the main memory 110 or It can be stored in secondary memory 120, or executed upon reception. When the computer program is executed, system 100 will perform the disclosed embodiment It can perform a variety of functions.

[0036] (2. Process Overview) From here, we will describe in detail the embodiments of the process for deterministic memory allocation. The process being described is, for example, a computer program or software package. It is executed by one or more hardware processors (e.g., processor 110). It can be understood that this can be realized in one or more software modules. The process to be explained involves source code, object code, and / or These can also be implemented as instructions represented in machine code. These instructions are hardware It may be executed directly by the air processor 110, or by object code and It can also be run by a virtual machine operating with the hardware processor 110. ru.

[0037] Alternatively, the process being described involves hardware components (e.g., general-purpose processors, integrated circuits). ICs (integrated circuits), application-specific integrated circuits (ASICs), digital signal processors (DSPs), Field-programmable gate array (FPGA) or other programmable logic device (Placement, individual gates or transistor logic, etc.), combinations of hardware components, It can be implemented as a combination of hardware and software components. To clearly demonstrate the interchangeability between hardware and software, various exemplary components are shown. Blocks, modules, circuits, and steps are generally referred to in this specification from the standpoint of their functionality. I will explain this in writing. Should such a function be implemented as hardware, or as software? Whether or not to install it depends on the specific application and design constraints imposed on the entire system. Therefore, it is possible to implement the described features in various ways for each specific application. However, such a decision to implement the invention should be interpreted as causing a departure from the scope of the present invention. There is no. Furthermore, the grouping of components, blocks, modules, circuits, or functions within a step The phrasing is for the purpose of facilitating explanation. Specific functions or steps are derived from the present invention. Without deviation, from one part, block, module, circuit, or step to another It can be moved to objects.

[0038] Furthermore, the processes described herein are illustrated by the specific arrangement and order of the subprocesses. However, each process has fewer, more, or different subprocesses and sub-processes. The process can be carried out with different arrangements and / or sequences. Furthermore, subprocesses can be identified. Even if described or illustrated in that order, any action that does not depend on the completion of other subprocesses A subprocess can run before, after, or in parallel with other independent subprocesses. It should be understood that this is acceptable.

[0039] (2.1. Introduction to Memory Pools) In fixed-size block allocation, a memory pool is used for memory management. Repool pre-allocates multiple memory blocks of the same block size into buckets. By allocating memory, dynamic memory allocation becomes possible. In other words, the bucket has a number of blocks. It is defined by the number of blocks and the block size. The size of a bucket is determined by the number of blocks and the block size. It is the product of Iz.

[0040] A memory pool can contain one or more buckets. If a bucket contains multiple buckets, a given bucket is different from one or more other buckets. It may have a memory block of a certain size and / or is different from one or more other buckets. It may have a number of memory blocks. In other words, a memory pool may contain multiple buckets. It is possible to configure the number of blocks and block size of each bucket independently. This is possible. Each bucket in the memory pool is the same fixed size as all other buckets. It may have a bucket. However, each bucket can be divided into a different number of blocks. As a simple example, the memory pools are 65,536 bytes each (i.e., 64 kilobytes). It can have four buckets of size (kb). The first of the buckets These can have 8,196 blocks, each with a size of 8 bytes, and the bucket The second of these has 1,024 blocks, each 64 bytes in size. And the third of the buckets is 6, all with a size of 1,024 bytes (1kb). It can have 4 blocks, and the fourth of the buckets is all 4,0 It can have 16 blocks of 96 bytes (4kb). Alternatively, within the memory pool... Two or more buckets may have different sizes. In this specification, the memory pool is Although primarily described as a collection of multiple buckets, the disclosed embodiments include a single bucket. Please understand that this can be applied to the memory pool consisting of these elements without any changes.

[0041] The size of the memory pool is determined at compile time (i.e., when the application is compiled). While it is fixed at runtime (when it is running), the application is fixed at runtime (for example, a real-time program). At any given time, allocate, access, and deallocate memory blocks within a given bucket of the memory pool. It is possible to do so. The important thing is that the memory pool is a pre-allocated memory. It provides dynamic allocation and deallocation in buffers, and can perform all of these within a fixed time. This is possible. Thus, the memory pool is deterministic, and therefore any allocation It guarantees a certain amount of time for the worst-case scenario of the release operation, so in real time It is suitable for applications where safety is critical.

[0042] Typically, the dimensions of the buckets in the memory pool (i.e., block size and number of blocks) ) needs to be known in advance at compile time. However, the application requires The number of blocks may depend on runtime (for example, input that is not known at compile time). Yes, and therefore it may not be known at compile time. Therefore, in real time In applications and embedded applications, the maximum number of blocks is limited by the application. It is hardcoded into the language. On the other hand, in programming languages ​​with discrete data types... The block size required by the application should be known at compile time. be.

[0043] (2.2. Introduction of Allocators) Programming languages ​​like C++ have high-level abstraction features that hide the actual size of allocations. It is being used. For example, the C++ standard library (std) has a map (std::map). ), list (std::list), set (std::set), promise (std: Containers such as :promise, shared pointers (std::shared_ptr), etc. These containers utilize allocators for memory allocation and deallocation. In other words, the allocator handles the allocation and deallocation of memory for a given container. Process the request.

[0044] The standard library provides a general-purpose allocator that is used by default, while containers use a different approach. Developers can accept and use custom allocators they have implemented as parameters. However, the actual allocation and deallocation by the allocator is an internal part of the standard library implementation. This is done in software code. Therefore, calls to custom allocators are typically made in software code. It does not appear. In other words, the bucket block size used by the custom allocator is It is usually impossible to derive it from the software code at compile time.

[0045] The allocator template is a new type that has a different data type that the container uses internally. It includes a rebind structure that instantiates the allocator. Figure 2 shows a rebind structure according to one embodiment. An example of source code for an allocator template with a bind structure is shown. As shown in the diagram, The rebind structure is a second data type that the container needs internally (for example, "ty" in Figure 2). Regarding "pename U"), the first data type (for example, "typename" in Figure 2) A new Instagram for the same allocator that could be a custom allocator used for "T" Create a container. For example, the "std::list" container is for a given data type. You can get a custom allocator, but not just a given data type, but a note for the node. The rebind structure also needs to be assigned to "std::list". Rebind the custom allocator to the internal "list_node" data type used by Na. Therefore, the software should be able to derive the data size required for the custom allocator. The location of the code is hidden within the rebind structure.

[0046] (2.3. Implementing the memory pool) Next, we will describe an example implementation of a memory pool that can be used in the disclosed embodiments. Since a complete explanation is not necessary to understand the disclosed embodiments, only the minimum implementation is illustrated. Therefore, some error checking has been omitted for readability. The implementation described is not thread-safe and assumes default consistency. It includes more robust error checking, is thread-safe, and / or default It is also possible not to assume consistency. The specific implementation used will determine which memory pool is used. Please understand that it may depend on specific applications.

[0047] In one embodiment, multiple instances of a memory pool are defined within the same application. It can be corrected. In applications where safety is critical, a memory pool can be used for safety. This can be important because it is often necessary to separate them. For example, multiple threads In an application that has a thread, to prevent threads from locking each other, each thread It is possible to instantiate separate memory pools for Red.

[0048] Figure 3 shows the source code for an example implementation of buckets in a memory pool according to one embodiment. Each bucket has a fixed block size (BlockSize) and a fixed number of blocks (B It has lockCount, and all of these have its bucket count Defined by the parameters passed to the struct. Each bucket also contains A pointer to the actual memory to be allocated (m_data) and each block in the bucket. A bitmap consisting of a ledger that uses 1 bit to track memory allocations. Includes the interface (m_ledger). The index of each block in the bucket is the same as the Corresponds to the index of each bit in the bitmap. When a block is allocated, that block You can set the bit in the bitmap corresponding to the lock index to "1". When a block is deallocated, the bitmap corresponding to the index of that block is generated. The bits within the program can be set to "0".

[0049] Furthermore, the bucket implementation example includes the following features: - The publicly available "belong()" function handles memory pointers passed as parameters in a garbled manner. Test whether it belongs to the set. - The publicly available "allocate() and deallocate()" functions are buckets Allocate and deallocate memory blocks within the system. - The private "find_contiguous_blocks()" function has parameters It takes a number "n" as input and tries to find a set of "n" consecutive blocks. For example, this function scans the ledger bitmap and finds n consecutive Find a sequence of "0"s in the bitmap that represents an empty block. If a block is found, it returns the index of the first block. If no free blocks are found, the number of blocks (BlockCount) is returned. - The private "set_blocks_in_use()" function uses an index and a number It receives "n" and assigns a set of "n" blocks starting from the index. Alternatively, mark it as "in use". For example, this function indexes the bitmap of the ledger. It is possible to set n bit sequences starting with "x" to "1". - The private "set_blocks_free()" function takes an index and a number "n". It receives and deals the set of n blocks starting from the index. It marks as "empty". For example, this function is an index of the ledger bitmap. It is possible to set n bit sequences starting with to "0".

[0050] Figure 4 shows the actual constructor and destructor for a bucket according to one embodiment. The source code for the example is shown. As shown in the diagram, the constructor is "std::mallo Using "c", the size of the bucket (BlockSize*) is used for the data in the bucket. Allocate memory equal to BlockCount and set the number of blocks (Bloc) for the ledger. Allocate memory equal to kCount. Note that this is an alternative to "std::malloc". Alternatively, you can use the "new" operator in the C++ programming language. In either case, The constructor initializes the memory allocated for the data and ledger to zero. If you need custom alignment instead of the default alignment, use the bucket constructor. This can be implemented (for example, by providing custom consistency for "std::malloc"). (For example, by replacing it with a function that can do so.)

[0051] Figure 5 shows an "alloca" for allocating blocks within a bucket according to one embodiment. The source code for an example implementation of the "te()" function is shown. As shown in the diagram, "allocate() The function takes the number of bytes to be allocated as an input parameter and blocks the number of bytes. Divide by the size and round up if necessary to convert to the number of blocks "n". The "allocate()" function is used in "find_contiguous_blocks The function `()` is called to determine if there is a set of n consecutive empty blocks. If there is no set of "n" consecutive empty blocks, the "allocate()" method is used. The number returns 0. If there are "n" consecutive empty blocks, the "allocate()" function The number of blocks is allocated by calling the "set_blocks_in_use()" function. Assuming this is done, the most recent set of these "n" consecutive currently allocated blocks in the bucket Returns a pointer to the first block.

[0052] Figure 6 shows a "dealloc" for releasing blocks in a bucket according to one embodiment. The source code for an example implementation of the "ate()" function is shown. As shown in the diagram, "deallocat The `e()` function accepts a pointer and the number of bytes to deallocate as input parameters. The `deallocate()` function takes the starting point and pointer of the bucket's data. The distance between them is calculated, and based on this pointer distance, the first block to be deallocated is... The index of the key is calculated. Next, the "deallocate()" function takes the input parameter Based on the number of bytes received as data, the number of blocks to be deallocated is calculated, and The function "set_blocks_free()" is called to calculate the first block free. Mark the block number starting with the index as deallocated.

[0053] As mentioned earlier, a memory pool is simply one or more buckets (often multiple buckets) It is a collection of buckets. Each bucket has two properties: block size and number of blocks. There is a patty. The set of pairs of this property for one or more buckets is a memory pool. Define an instance of the memory pool. Figure 7 shows a definition of a memory pool according to one embodiment. The source code for an example implementation of the template structure is shown below. The "id" parameter is a memory pool Identifies an instance of the memory pool. The identifier is an integer (for example, the first instance of the memory pool). (e.g., "1" for the instance, "2" for the second instance of the memory pool, etc.) or others It can be a data type (for example, a string). In the default implementation, the bucket is Define a memory pool that has no contents (i.e., empty tuples).

[0054] Figure 8 shows a template structure for defining a memory pool according to one embodiment. The source code for an implementation example that specializes in application examples is shown. This source code is A Even if provided in the header file used to compile the application Good. The template structure consists of three buckets with three different configurations, and identifiers. This defines a memory pool of "1". The first bucket has a block size of 16 bytes. The number of locks is 10000, and the second bucket has a block size of 32 bytes and 1 block. 0000, the third bucket has a block size of 1024 bytes and 50000 blocks. This is just one example, and the exact number and configuration of buckets in the memory pool will vary. It's important to understand that it depends on the application using the tool. The key is to note You can create or modify files that define the repool, and use the memory pool for a specific application. The ability to customize it to suit the application is a key feature.

[0055] Figure 9 shows an example implementation of several structures defining the characteristics of a memory pool according to one embodiment. The source code is shown. The bucket count characteristic is within the memory pool. Represents the size of the tuple (i.e., the number of buckets). Pool type characteristic (pool_ty pe) is an array of buckets with a size equal to the number of buckets. The functions "e" and "get_count" take the identifier (id) of the memory pool and its memory The bucket block identified by the bucket index (Idx) in the pool tuple Returns the size and block count properties, respectively.

[0056] Figure 10 shows the source code of an example implementation of a function for creating a memory pool according to one embodiment. This shows the code. As shown in the diagram, the "get_instance()" function is used to determine the memory pool. Instantiated using an identifier, and defining a static local array (pool_type). The `get_instance()` function takes each bucket in the memory pool tuple. Then, call the "get_size()" function and the "get_count()" function, The array is instantiated in an actual bucket, and this creates a memory pool.

[0057] Figure 11 shows the source code of an example implementation of memory pool initialization according to one embodiment. As shown, the "is_defined()" function is used to find a memory that has the specified identifier. Whether the bucket contains at least one bucket (true) or does not contain any buckets (false) It returns a boolean value indicating ). The "initialize()" function initializes the memory pool. This is a helper function for creating a tangled memory pool. As mentioned earlier, the default memory pool is These two functions are useful because an object can sometimes be instantiated without a ket. .

[0058] (2.4. Bucket Selection) When an allocation is performed, the allocator determines that the allocation is for a single data object. I don't have information on whether it applies to one thing or to multiple data objects. However, the allocator only receives the number of bytes of data to be stored. In other words, allocation At this level, information about the data object to be stored cannot be obtained. Therefore, Cater is based on the number of bytes of data to be stored, not the number of data objects to be stored. Therefore, an appropriate bucket must be selected for the given allocation. This selection is, It can be implemented in various ways.

[0059] For example, an application will wait until it reaches a bucket large enough to store the data. Then, you can simply scan the buckets in the memory pool. In this case, the bucket The blocks should be sorted by their block size. Figure 12 shows one embodiment. Source code for an example implementation of the "allocate()" function that utilizes this first-fit strategy. The code is shown below. As illustrated, the "allocate()" function is used to determine the size of the data to be stored. Find buckets with a block size greater than or equal to the input parameter (bytes) representing the size. The buckets are processed repeatedly until such a bucket is found. The `cate()` function allocates data to the bucket and returns a pointer to that bucket. If not, the "allocate()" function will indicate that the allocation failed. It throws an exception. This first-fit strategy is used with "std::map" and "std::l Suitable for containers that allocate memory for each data object, such as "ist". However, other cons that allocate memory for multiple data objects simultaneously are doing so. Tenor (for example, memory for both the hash node and a pointer to the hash node) To allocate a "std::unordered_map" (etc.), this first fit The method may not be suitable.

[0060] As a more advanced strategy, at compile time for the application's software code It is possible to perform analysis on this. Using the results of that analysis, a specific bucket can be classified into a specific data type. It can be bound to (for example, based on "typename"). In other words, It is possible to configure specific buckets to match specific data types.

[0061] Containers of all types (for example, "std::map", "std::list", As an alternative runtime method that would be suitable for "std::unordered_map", etc. The `allocate()` function uses the least amount of memory and / or the minimum number of allocations. You can select a bucket that will provide the target block. Figure 13 shows one embodiment. The source code of an example implementation of an info structure to assist in bucket selection. The diagram shows the amount of waste for each allocation, and the allocation The calculation compares two buckets based on the number of blocks that would likely be needed for allocation. Define the arithmetic operator. In this case, the amount of waste is the size of the data to be stored and the amount of data to store. It is defined as the difference in bytes between the total size of the blocks that would be required and the actual size. The operator, if the waste amounts of the two buckets are not equal, selects the bucket with the smallest waste amount. Prioritize the bucket that requires the fewest blocks if the waste amounts of the two buckets are equal. It is designed to minimize waste by prioritizing efficiency. The scalar sorts the set of buckets by the amount of waste each bucket has, and sorts the bucket that has the least amount of waste. It can be used to select a set.

[0062] Figure 14 shows a memory pool structure utilizing the info structure from Figure 13, according to one embodiment. Source code for an example implementation of the "allocate()" function for allocating a bucket. As shown in the diagram, the "allocate()" function allocates memory to each bucket in the memory pool. The amount of waste and the number of blocks required are calculated, and these values ​​are stored in an array of an info structure. Each entry in the column corresponds precisely to one of the buckets. Next, "allocate The `()` function determines the least wasteful bucket based on the operators defined in the info structure. Sort the array from the first bucket to the one with the most buckets. Then, use the "allocate()" function. From this sorted array, you can select the bucket with the least waste. ru.

[0063] Because the allocator needs to allocate a contiguous set of blocks, the memory pool Memory can become fragmented within a socket. However, application developers can fragment memory during development. By paying attention to the allocation and deallocation patterns and using separate memory pools, memory outages can be avoided. This can alleviate cleavage.

[0064] Figure 15 shows a "deal" for releasing buckets in a memory pool according to one embodiment. The source code for an example implementation of the "locate()" function is shown below. As shown in the diagram, "deallo The `cate()` function accepts a pointer and the number of bytes as input parameters. The `allocate()` function checks whether a pointer belongs to a bucket, and if it does, If so, the "deallocate()" function is used to release blocks in the bucket. Call it.

[0065] (2.5. Implementation of the allocator) The allocator used in the disclosed embodiments is "std::allocator_t You may implement a C++ allocator model that is compatible with "raits". Components can silently transition from one allocator to another. Furthermore, when moving data between different containers, the allocator uses a single memory pool or This creates the possibility of moving data to a different memory pool, resulting in non-deterministic memory allocation. It is possible. Therefore, in one embodiment, each allocator is memory To ensure that data cannot be moved between pools, the memory pools are configured at compile time. It is bound to a single, specific instance.

[0066] In one embodiment, each allocator is defined in the memory pool to which it is bound. Therefore, it is implemented to allocate from another resource. As mentioned above, memory A bucket may be instantiated when there is no bucket (i.e., it is undefined). Therefore, the allocator can properly manage its memory pool even if it is undefined. It is better if it is possible. Therefore, the allocator is defined as the memory pool to which it is bound. Until configured, it will allocate from default resources such as the memory heap. It is also possible. And once the memory pool is defined, the allocator will automatically use the memory pool. We will begin the allocation.

[0067] Figure 16 shows a data object nested in the same memory pool according to one embodiment. An example of a usage scenario is shown. As shown in the figure, a static pool allocator (stati c_pool_allocator) contains the data type and memory pool identifier, It has two template arguments. In this scenario, a list object and a list The vector of objects is in the same memory pool (i.e., "AllocId=1") It is allocated from the memory pool (identified as such). When a value is entered into the vector, Data for vectors and data for other vectors are stored in the same memory pool.

[0068] Figure 17 shows a separate memory for nested data objects according to one embodiment. This is a diagram showing another use scenario in which the pool is used. As shown in the diagram, list (i.e.) "list_allocator") and vectors (i.e., "vector_a") Two different allocators for the template "static_ Created from "pool_allocator". Each allocator has a different memory. It is bound to the repool. For example, the restore locator is bound to the first identifier (i.e., " The vector allocator is bound to a memory pool with AllocId=1, and the vector allocator is the Binds to a memory pool with identifier 2 (i.e., "AllocId=2") As a result, when values ​​are input into the vector, the data for the list becomes the data for the vector. It is stored in a separate memory pool.

[0069] Figure 18 shows a static pool allocator (static_pool_al) according to one embodiment. The source code for an example implementation of the locator is shown. It is noteworthy that the example implementation uses allocation. It includes only the code most relevant to understanding, while omitting code irrelevant to understanding the assignment. The thing is that much of the omitted code is "std::pmr::polymor This is the same code as "phic_allocator".

[0070] As shown in the diagram, the rebind structure rebinds static pool allocators only to the same memory pool. Bind. Specifically, the rebind structure reinstances the static pool allocator. When creating a copy, use the same identifier in the memory pool. Similarly, copy constructor The call assignment operator also uses the same memory pool identifier, and the static pool allocator is a single memory pool allocator. It is bound to a memory pool, and data cannot be moved between different memory pools. We guarantee that.

[0071] Furthermore, the static pool allocator uses upstream resources (m_upstream_resour Define ce) and this is set as the default resource (pmr::get_default It is initialized by calling the "t_resource()" function. Therefore, memory Even if the pool identifier is undefined, the static pool allocator can still allocate memory. Yes. In particular, if the memory pool is undefined, the static pool allocator will default to the default resource. Allocate memory from the memory heap (for example, the memory heap available to higher-level applications). ru.

[0072] Figure 19 shows the "allocate()" function of a static pool allocator according to one embodiment. This is the source code for an implementation example. As shown in the diagram, if a memory pool is defined, The function allocates memory from the memory pool bound to the allocator. Otherwise, if a memory pool is not defined, this function will take memory from the upstream resources. Allocate memory. The runtime portion while the memory pool is defined is stable in real time. It can be considered a safe mode that is suitable and guaranteed in environments where wholeness is important. When a memory pool is not defined during runtime, it is not suitable for environments where real-time safety is critical. It can be considered a mode that is neither guaranteed nor guaranteed.

[0073] (2.6. Collection of Data Type Sizes) Of particular note is the static pool allocator (static_pool) as shown in Figure 19. In the `allocate()` function of `_allocator::allocate)` The data type (T) on which the assignment is being performed is known. Therefore, the execution Sometimes the "allocate()" function outputs the size of the data type and memory allocation. It is possible to log the size of the data type being processed in the runtime log. However, This does not guarantee complete coverage for all data types, so it is not ideal. It is not possible. For example, data types that are rarely assigned may not be recorded within a given finite execution time. It may end. Furthermore, complete coverage of the allocation in some applications may be Even if guaranteed, it would be impossible or impractical for all real-world applications. Furthermore, developers generally need information about the call graph (for example, how at runtime, And it doesn't explain why it arrived at the "allocate()" function. It is difficult to prove that all possible data types have been considered.

[0074] Ideally, all calls to the static pool allocator's "allocate()" function would be... Output is regardless of the runtime flow (for example, if the function is of a specific data type at runtime). In contrast, everything in the compiled code (regardless of whether it was actually called or not). They will be instantiated and registered for the data type. Also, these assignments It would also be useful to register all call paths that lead to this. In one embodiment, this To enable their registration, instrument code is injected into the source code.

[0075] Figure 20 shows the source code of an example implementation of an instrument namespace according to one embodiment. This indicates the type. As shown in the diagram, the instrument namespace has three arguments and "type It is defined as a template that has a dummy function called "_reg()". The three arguments of the packet are the memory pool identifier, the data type name, and the data type name. This is the size. The "type_reg()" function does not actually perform any action, so it is a dummy. It is a function. Rather, the sole purpose of the dummy function is to record the three arguments for each assignment. Therefore, it must be understood that dummy functions can be given any name. Furthermore, although the dummy function is illustrated as empty, in another embodiment... It can contain one or more instructions.

[0076] Figure 21 shows the "alloc" of the static pool allocator exemplified in Figure 19, according to one embodiment. This shows the source code of one example of instrument code injected into the "ate()" function. As shown in the diagram, the "allocate()" function has "instrument::type A call to the function "_reg()" is injected. Dummy "type_reg()" A function call requires the memory pool identifier, the name of the data type, and the size of the data type. This is passed to an empty type_reg() function.

[0077] As mentioned above, the "type_reg()" function is a dummy function and is actually applied to the app. This does not affect the operation of the application in any way. It refers to the call to the "type_reg()" function. The definition is the object code generated by compiling the application's source code. The key is that it can be detected from the source code of the application. After compiling the code, the analysis software scans the compiled object code. This allows you to identify each occurrence of the "type_reg()" function call. Next, the analysis software extracts the memory pool from the identified object code fragments. Extract the identifier, data type name, and data type size, and the associated data types and their It is possible to register each memory pool with the corresponding size for those data types. Based on these registrations, the analysis software determines the appropriate bucket configuration for each memory pool. It is possible. Advantageously, the data from its memory pool can be retrieved within a finite execution time. Regardless of whether memory is allocated to the type, there is a possibility of using the memory pool. This ensures that all data types are accurately represented.

[0078] Figure 22 shows the "deallocate()" function of a static pool allocator according to one embodiment. The source code for an example implementation of the function is shown below. As shown in the diagram, if a memory pool is defined... The `deallocate()` function is used for the `deallocate()` function of the memory pool. Use a function to deallocate memory from the memory pool. Otherwise, the memory pool will remain unallocated. If defined, the `deallocate()` function allocates from upstream resources. unlock.

[0079] (2.7. Generating a bucket definition) In one embodiment, in order to collect bucket definitions according to the actual allocation, first, Compiles source code into object code. For example, source code written in C++ In the case of the source code, the "Clang" compiler provides an intermediate compiler that makes parsing and manipulation easy. Compatibility with the bitcode "LLVM (an acronym for Low-Level Virtual Machine)" It is possible to do this. When compiling the source code, the following parameters can be used. Setting it to 1 is convenient (assuming the "Clang" compiler, but other compilers...) (Translatable to Ira as well) -g ensures that the call graph contains "file:line" information for generating the call graph. . Specifying -O0 removes calls to dummy functions injected during optimization by the compiler. Because this could potentially cause problems, we will prevent the compiler from performing optimizations. -emit-llvm converts source code into bitcode instead of native instructions. Make it pile-like. -DNDEBUG should retrieve the release version of the data structure.

[0080] Next, all unique data types assigned to each instance in each memory pool To form the list, one or more paths are implemented in the compiled code. Furthermore, paths allow us to build a call graph for all assignments. This is useful for debugging purposes and also for understanding how the application works. It can also provide insights into the process. The path is generated by the "Clang" compiler. This is implemented using the "LLVM opt" tool on the "LLVM" bitcode. This is possible. The "LLVM opt" tool can be used for "LLVM" bitcode files. A custom path can be executed. For efficiency, the compiler uses multiple bitcodes. When generating a bitcode file, multiple bitcode files can be combined into a single bitcode file. Combine them so that each pass is executed only for a single synthetic bitcode file. That's fine.

[0081] Figure 23 shows the source code of an example of path implementation according to one embodiment. The illustrated path is Using regular expressions, we extract and solve the function call to the dummy "type_reg()" function. This is a function path that generates a list of analyzed and extracted data. In particular, each row of the list is Me represents a single function call to the function "type_reg()", and dummy "type_ The memory pool passed as a parameter in a function call to the "reg()" function The identifier, the size of the data type that uses that memory pool, and the amount of memory pool used The list includes the names of the data types. The list is possibly associated with a single memory pool. Includes a single data type associated with multiple data types and / or multiple memory pools. Hmm, understand that it may contain rows that associate one or more data types with one or more memory pools. I want to be treated that way.

[0082] In reality, instead of "llvm::FunctionPass", use "llvm::Mo Using "dulePass", call graphs from the entire software module being analyzed. It can generate a . Module entry point (for example, "main()") It is possible to perform a depth-first search starting from the function. (Type_reg()) Each time a call to a number is discovered, the data type of the allocation (e.g., size and / or name) is registered (e.g., output or stored in a list as described above), and the call graph of the allocation is registered (e.g., output or stored in a file). For efficiency, recursions in the call graph are detected, and branches in the call graph representing those recursions can be dropped since they do not end in an allocation. The result of this path is a list of all unique allocations. As described above, this list of unique <000U900>allocations can include, for each allocation, the identifier of the memory pool, the size of the data type allocated from that memory pool, and / or the name of that data type. It should be understood that the same allocation (i.e., the same combination of memory pool identifier, data type size, and data type name) can be detected multiple times during the path. Therefore, to obtain a list of unique allocations, duplicates can be removed for the allocations in the list so that there is only one entry for each unique combination of memory pool identifier, data type size, and

[0083] Thirdly, the definition of the memory pool and the definition of the buckets used by the memory pool are generated from the list of unique allocations generated by the path. For example, the list of unique allocations can be converted into a header file that defines a memory pool specialized according to the allocations in the list. In other words, each memory pool can be defined in a header file using a bucket descriptor that optimizes the bucket configuration according to the data types of the allocations in the list of unique allocations that make up its

[0084] memory pool identifier.

[0084] Figure 24 shows a simple example using one embodiment of the static pool allocator described herein. The source code of the application is shown. This application is not a real-world example, Please understand that the disclosed embodiments are used solely to demonstrate their operation. As shown, the application calls the "f()" function which in turn calls the "x()" function. It contains the "main()" function. The "x()" function is in the memory pool with identifier "3". Instantiate an integer list named "lst" in the bound static pool allocator. Add the integer "1" to "lst".

[0085] Figure 25 shows the path of a simple application illustrated in Figure 24, according to one embodiment. The call graph generated for the detected assignments is shown. In particular, the illustrated call The graph was triggered by adding the integer "1" to the list "lst". This is for code allocation. Therefore, the call graph is for memory pool identification. Child "3", Data type size "24" (i.e., the size of the list node in bytes) , and associated with the data type name "list_node". Call graph From this, you can learn about the mechanism and reasons behind each allocation.

[0086] Of note is that the call graph generated in this way includes virtual calls and function pointers. It may be incomplete due to calls via and the possibility of inline assembly. It is a matter of nature. However, this problem is that the call graph is a list of unique assignments and By combining these, it becomes possible to guarantee that all allocations are covered. This can be mitigated. This approach involves calling a method that is never called during execution. It is possible to detect orphan assignments, which are unreachable assignments (for example, call (It does not exist in the graph, but it does exist in the list of unique assignments). From a safety perspective. Generally speaking, it is better to include an over-allocation than an under-allocation.

[0087] In one embodiment using the "Clang" compiler, the analysis software uses "opt The command can be used to execute on the bitcode generated by the compiler. Yes, it is possible. For example, you can implement the parsing path on the bitcode of the application exemplified in Figure 24. To run the compiled Shared Object (SO) library file, follow these steps: You can use the ND. opt -load alloc-analyzer.so -alloc-analy ze -gen-hdr my_defs.hpp -entry-point “ma in”< home / program.bc -o / dev / null Basically, this command is used by the allocator analysis tool (alloc_analyzer.so Load the bitcode file (home / program.bc) and the "main This function generates a header file (my_defs.hpp) starting from the "()" function. be.

[0088] Figure 26 shows a bitcode for a simple application illustrated in Figure 24, according to one embodiment. Example header file generated based on the path of the analysis software for the code (my_de This shows fs.hpp). As shown in the diagram, the header file has the memory identifier "3". It includes buckets (bucket_cfg24) and bucket descriptors for the pool (buck et_descriptors). It should be noted that the generated buckets are optimized for the list nodes used by the list in the application example. Specifically, the block size of the bucket is 24 bytes, and the block is exactly aligned with the 24-byte list nodes used in the list. In other words, each node of the list exactly corresponds to one block of the bucket. In more complex applications, it should be understood that the header file can include multiple buckets for multiple memory pools. In this case, the bucket descriptor may include a tuple with multiple buckets, and the tuple may be defined for multiple memory pools rather

[0089] than a single memory pool. When the header file is generated as described above, the application can be recompiled with the newly generated header file that optimally defines each memory pool and each bucket used by each memory pool. It should be noted that when the application is run without these definitions, the application still runs properly, but by implementing the static pool allocator described above, it utilizes upstream resources (e.g., the memory heap). When the application is recompiled As a result, the application allocates memory from the default memory resources and the memory pool. These assignments can be seamlessly switched without making any changes to the application itself. It can be replaced.

[0090] (2.8. Examples of Embodiments) Advantageously, the embodiments described herein are suitable for applications where safety is critical. Guarantees deterministic memory allocation. Uses a memory pool with a fixed bucket size. This can guarantee deterministic behavior, but it requires properly configuring these memory pools. This is complex, for example, in the context of the C++ allocator model. Therefore The embodiment involves injecting instrument code into a custom allocator, and then each allocation To extract these attributes, the instrument code is detected at compile time. The attributes are then used to generate a header file that optimally configures the memory pool. This is possible in applications where real-time and / or security is critical. This presents a verifiable and deterministic memory allocation solution for this purpose.

[0091] Figure 27 shows an example of optimizing the memory pool used by an application according to one embodiment. An exemplary overall process 200 is shown for this purpose. One or more subprocesses of process 200 are shown. , and possibly all of them, optimization tools (e.g., analysis software described herein) Implement as one or more software modules (including or consisting of) This can be done, and it can include or work in conjunction with a compiler. The optimization tool is run by one or more processors 110 of one or more systems 100. Therefore, the one or more memory pools used by the application during runtime are optimized. The header files to be defined can be generated at compile time.

[0092] First, in subprocess 210, the source code for the application is bit It is compiled into source code. For process 200 to be effective, the source code is Between each assignment, an allocator or other call a dummy function using the relevant arguments. You will need to use the assignment function. For example, the "type" example described in this specification. The static pool allocation described herein calls dummy functions such as the "_reg()" function. The data can also be used as an allocator. Related arguments passed in a call to a dummy function This is the identifier of the memory pool to which the allocator is bound, and the note from the memory pool. It can include one or more attributes of the data type to which it is assigned. While this specification has mainly discussed C++ allocator models, dummy functions are , standard allocation used by other programming languages ​​to achieve the same result It should be understood that functions and schemes can be incorporated in a similar manner.

[0093] In subprocess 220, the bit code is analyzed. In particular, the optimization tool is bit Scan the code and use an allocation function (e.g., a custom C++ allocator) to perform the task. It is possible to identify a segment of bitcode that represents a call to the MEE function. Optimization The tool reaches the end of the bitcode (i.e., in subprocess 230, Scan the bitcode until it reads "Yes". If the end of the bitcode is not yet reached... Unless not (i.e., "No" in subprocess 230), the optimization tool The program determines whether the current view of the bitcode represents a call to a dummy function. To reject. For example, an optimization tool will move the bitcode sliding window to a dummy function. Compare with known bitcode fragments that represent the call, or alternative pattern matching Use the scheme to identify each instance of a dummy function call in the bitcode. It is possible.

[0094] The optimization tool detects calls to dummy functions due to the assignment function (i.e., Each time the answer is "Yes" in subprocess 240, the assignment information from that call is obtained. Extract and register the parameters. For example, the optimization tool will represent the parameters passed to the dummy function. Data can be extracted. These parameters are allocated by the memory allocation function. The identifier of the memory pool to be allocated, the memory allocated by the allocation function The size of the data type, and / or the data type whose memory is allocated by the allocation function. The name can be disclosed. These parameters are extracted from the bitcode and bit It is possible to convert from tcode to source code. Next, the converted parameters are assigned. They may be stored as assignments within the list. In one embodiment, only unique assignments It is stored in a list. In this case, if an assignment already appears in the list, it is stored in a list. It may be possible to discard items without duplicating them within the stock. Alternatively, all allocations may be listed. You may add them to the list and then remove any duplicate assignments from the final list. As explained elsewhere, you can also generate a call graph for each assignment. The call to the dummy function is not detected in the current view of the bitcode (i.e., If the result in process 240 is "No", the optimization tool will scan the bitcode. Continue with the program.

[0095] Once the entire bitcode is scanned, a complete list of unique assignments is generated (and Optionally, generate a call graph for one or more (potentially all) assignments. When the process is completed (i.e., "Yes" is selected in subprocess 230), the optimization process The system can be automated (e.g., without user intervention) or semi-automated (e.g., with some users) (With the involvement of the processor) the header file can be generated in subprocess 260. In particular, the header file is registered in one or more iterations of subprocess 250. It can be generated from a list of arbitrary assignments. As discussed elsewhere in this specification, The file defines one or more buckets (for example, block size and number of blocks). The value of and the definition of one or more memory pools (for example, one or more references to bucket definitions) It can include (pull).

[0096] These definitions can be optimized for a specific assignment within a list of assignments. For example, an optimization tool might adjust the block size of a bucket in a particular memory pool. Matching the size of the data type to which data is allocated from a specific memory pool, or other methods It can be defined to be consistent with 16 bytes, 32 bytes, Three different data types with different sizes, 1024 bytes and 1024 bytes, are all in memory. If associated with a file, the optimization tool will handle 16-byte, 32-byte, and 10-byte files. Define a bucket with a block size of 24 bytes, and the memory pool will have these three buckets It can be defined to include a tuple of ket. Alternatively, the optimization tool can use 16 ba Define a bucket with a block size of 1024 bytes, and this memory pool It can also be defined to include two buckets. In this case, the size is 32 bytes. Each instantiation of the data type it possesses is in a bucket with a block size of 16 bytes. Two blocks can be used. In either case, within the bucket of each memory pool The block size should match the size of the data type that uses that memory pool.

[0097] It should be understood that there are numerous strategies for creating a consistent bucket using this method. The optimization tool is any one or more tools for deriving the bucket configuration from the registered allocation. It can be configured to utilize the strategy. In a straightforward strategy, the optimization tool divides A bucket for each unique data size in the list of assignments (i.e., for the data size Create buckets with equal block sizes, and then associate them with that memory pool. Each memory pool contains buckets with block sizes that match all data sizes. This defines the data type in the registered assignment. Bucket definitions can be derived based on size, and the data used in that memory pool You can select a bucket definition that defines each memory pool based on the data type size. When two memory pools use buckets with the same configuration, the optimization tool will optimize the buckets. The ability to define a bucket once and use that single bucket definition for both memory pool definitions. Please understand this. In other words, a bucket definition is reused across multiple memory pools. It can be used.

[0098] (3. Usage example) The disclosed embodiments allow any software that requires or desires deterministic memory allocation. It can be used to provide deterministic memory allocation in a software application. Yes, it is possible. The biggest advantage is that it is suitable for real-time applications, especially when security is critical in real time. It can be seen in certain applications. Such applications are limited However, autonomous or semi-autonomous vehicles, robots, and critical infrastructure (for example, Power plants, power grids, networks, etc.), rockets, satellites, medical equipment, and / or This includes control and / or safety systems for similar items.

[0099] The above description of the disclosed embodiments indicates that anyone skilled in the art could manufacture or use the present invention. These are provided for the purpose of doing so. Various modifications to these embodiments are available. As will be readily apparent to the experts, the general principles described herein do not represent the spirit or scope of the invention. It is possible to apply this to other embodiments without departing from this specification. Thus, The descriptions and drawings presented represent currently preferred embodiments of the present invention, and therefore, the present invention Therefore, it will be understood that this represents a broadly intended subject matter. Furthermore, the scope of this invention This scope fully encompasses other embodiments that may be obvious to those skilled in the art, and also extends the scope of the present invention. It should be understood that the boundaries are not limited.

[0100] In this specification, "at least one of A, B, or C" and "one of A, B, or C" are used. "One or more," "At least one of A, B, and C," "One or more of A, B, and C," Combinations such as "A, B, C, or any combination thereof" are A, B, and / Or any combination of C, and any multiple of A, B, or C. It may include: Specifically, "at least one of A, B, or C", "A, B, and is one or more of C's, at least one of A, B, and C's, one of A, B, and C's The above, combinations such as "A, B, C, or any combination thereof" are only A, It may be B only, C only, A and B, A and C, B and C, or A and B and C. Any such combination includes one or more of its components A, B, and / or C. Yes, that is fine. For example, combinations of A and B include one A and multiple B, multiple A and one B, Alternatively, it may include multiple A's and multiple B's.

Claims

1. A method for automatically generating a header file for defining a memory pool for deterministic memory allocation, the method using at least one hardware processor, Steps include receiving bitcode representing the compiled source code of an application, wherein the source code includes an allocation function for allocating memory by calling a dummy function that uses one or more parameters, the one or more parameters including the size of a data type and an identifier of a memory pool, Automatically, The steps include scanning the bitcode to detect each call to the dummy function within the bitcode, For each detected call to the dummy function, the steps include: extracting one or more parameters used in the detected call to the dummy function; generating an allocation record from the extracted one or more parameters, each generated allocation record including the size of the data type from the extracted one or more parameters and the identifier of the memory pool; Based on the generated allocation record, the definition includes one or more bucket definitions and one or more memory pool definitions, each of which includes the step of generating a header file that identifies at least one of the one or more buckets, The step of generating the aforementioned header file is: For each unique size of the generated allocation record, the step of generating at least one definition of a bucket that includes a block size consistent with that unique size, A method comprising the step of generating a definition of a memory pool having each unique identifier of the generated allocation record.

2. The method according to claim 1, wherein the step of receiving the bit code includes the step of compiling the source code into the bit code, and the method further includes the step of recompiling the source code with the header file after the step of generating the header file using the at least one hardware processor.

3. The method according to claim 1, wherein the step of generating a definition of at least one bucket having a block size that matches its unique size includes the step of generating a definition of a bucket having a block size that matches its unique size.

4. The method according to claim 1, wherein each definition of a memory pool includes, for each unique size associated with the identifier of that memory pool in the generated allocation record, a reference to one of the definitions of one or more buckets whose block size matches that unique size.

5. The method according to claim 4, wherein the one or more parameters further include identifiers of the data types to be stored in the memory pool.

6. The method according to claim 1, wherein each of the one or more memory pools' definitions includes a tuple, the tuple includes one or more references, and each of the one or more references identifies one of the one or more buckets.

7. The method according to claim 1, wherein in the bit code, each instance of the allocation function is bound to the single memory pool such that the allocation function is not allocated from any memory pool other than the single memory pool.

8. The aforementioned assignment function is, While the memory pool is undefined, memory is allocated from the upstream resources available to the application. The method according to claim 1, configured to allocate memory from the memory pool while the memory pool is defined.

9. The method according to claim 1, wherein the source code is written in the C++ programming language.

10. The method according to claim 9, wherein the allocation function is a custom allocator that conforms to the allocator model of the C++ programming language.

11. The method according to claim 1, further comprising the step of using at least one hardware processor to generate a call graph representing the path of the function call from the application's entry point to the assignment function for each call to the assignment function in the bitcode.

12. A non-temporary computer-readable medium having instructions stored therein, wherein when the instructions are executed by a processor, the processor... Steps include receiving bitcode representing the compiled source code of an application, wherein the source code includes an allocation function for allocating memory by calling a dummy function that uses one or more parameters, the one or more parameters including the size of a data type and an identifier of a memory pool, Automatically, The steps include scanning the bitcode to detect each call to the dummy function within the bitcode, For each detected call to the dummy function, the steps include: extracting one or more parameters used in the detected call to the dummy function; generating an allocation record from the extracted one or more parameters, each generated allocation record including the size of the data type from the extracted one or more parameters and the identifier of the memory pool; Based on the generated allocation record, the system includes the definition of one or more buckets and the definition of one or more memory pools, and each of the definitions of the one or more memory pools includes the step of generating a header file that identifies at least one of the one or more buckets, The step of generating the aforementioned header file is: For each unique size of the generated allocation record, the step of generating at least one definition of a bucket that includes a block size consistent with that unique size, A non-temporary computer-readable medium comprising the step of generating a definition of a memory pool having each unique identifier of the generated allocation record.

13. The non-temporary computer-readable medium according to claim 12, wherein the step of receiving the bit code includes the step of compiling the source code into the bit code, and the instruction causes the processor to generate the header file and then recompile the source code with the header file.

14. The non-temporary computer-readable medium according to claim 12, wherein each definition of a memory pool includes a reference to one of the definitions of one or more buckets whose block size matches that unique size for each unique size associated with the identifier of that memory pool in the generated allocation record.

15. The non-temporary computer-readable medium according to claim 12, wherein the allocation function is a custom allocator that conforms to the allocator model of the C++ programming language.

16. At least one hardware processor, One or more software modules, when executed by at least one hardware processor, Steps include receiving bitcode representing the compiled source code of an application, wherein the source code includes an allocation function for allocating memory by calling a dummy function that uses one or more parameters, the one or more parameters including the size of a data type and an identifier of a memory pool, Automatically, The steps include scanning the bitcode to detect each call to the dummy function within the bitcode, For each detected call to the dummy function, the steps include: extracting one or more parameters used in the detected call to the dummy function; generating an allocation record from the extracted one or more parameters, each generated allocation record including the size of the data type from the extracted one or more parameters and the identifier of the memory pool; Based on the generated allocation record, the definition includes one or more bucket definitions and one or more memory pool definitions, each of which includes the step of generating a header file that identifies at least one of the one or more buckets, The step of generating the aforementioned header file is: For each unique size of the generated allocation record, the step of generating at least one definition of a bucket that includes a block size consistent with that unique size, A system comprising the step of generating a definition of a memory pool having each unique identifier of the generated allocation record.

17. The system according to claim 16, wherein the step of receiving the bitcode includes the step of compiling the source code into the bitcode, and the one or more software modules are further configured to generate the header file and then recompile the source code with the header file.

Images