Application service metadata encoding and initialization

Abstract

The present invention generally relates to the field of data processing, and more particularly to techniques for encoding and initializing service metadata required for efficiently running applications written in object-oriented programming languages. Specifically, these techniques include obtaining an encoded representation of the service metadata and storing it in an initialized read-only data segment of the application's executable file, and reserving at least partially an uninitialized data segment of the executable file for the service metadata itself. The encoded representation is then decoded during runtime of the application to initialize the service metadata in the reserved uninitialized data segment. This can reduce the application's disk footprint (executable file size) because only the encoded representation of the service metadata is stored in the executable file, rather than the actual service metadata. In addition, the encoded representation of the service metadata can be quickly decoded, thereby reducing the application's startup time.

Description

Technical Field

[0001] The present invention relates generally to the field of data processing, and more particularly to techniques for encoding and initializing service metadata required to efficiently run applications written in object-oriented programming languages. Background Art

[0002] For an application to run properly on user equipment (UE), such as a desktop computer or mobile phone, it requires service metadata, which includes various runtime data. This metadata is typically generated by a compiler, which, together with a linker, generates the application's executable file from the application's source code. There are at least two methods for generating service metadata, each with its own advantages and disadvantages.

[0003] The first approach is embodied in ahead-of-time (AOT) compilers, which generate the service metadata required by an application in advance and store it in the application's executable file. The service metadata is then loaded from the executable file at runtime. This AOT compilation results in an unnecessary and undesirable increase in the executable file size (i.e., disk footprint) and slows down application startup due to the relatively large amount of service metadata that needs to be loaded.

[0004] The second (opposite) approach is embodied in just-in-time (JIT) compilers, which generate the service metadata required by the application on demand at runtime. It should be noted that the second approach can be used in conjunction with the first approach (i.e., some service metadata can be generated in advance, while the rest can be generated on demand). While the second approach eliminates the disk usage overhead inherent in the first approach, it increases the application's startup and execution times. Furthermore, if used in conjunction with the first approach, the second approach can also impact the optimization capabilities of the AOT compiler. Summary of the Invention

[0005] This summary briefly introduces some concepts that will be further described in the detailed description. This summary is not intended to identify key features of the invention, nor is it intended to limit the scope of the invention.

[0006] The purpose of the present invention is to provide a technical solution that enables obtaining a coded representation of an application's service metadata at compile time, and then initializing the service metadata according to the coded representation at startup.

[0007] The above objects are achieved by the features of the independent claims in the appended claims. Further embodiments and examples are apparent from the dependent claims, the detailed description and the drawings.

[0008] According to a first aspect, a device for encoding service metadata for an application is provided. The device provided in the first aspect includes at least one processor and a memory coupled to the at least one processor. The memory is configured to store processor-executable instructions that cause the at least one processor to operate as follows. First, the at least one processor receives source code for the application and uses the source code to determine the service metadata for the application. Then, the at least one processor obtains an encoded representation of the service metadata. Next, the at least one processor compiles the source code to generate an executable file for the application. The executable file includes an initialized read-only data segment and an uninitialized data segment. The at least one processor reserves at least part of the uninitialized data segment of the executable file for the service metadata. Thereafter, the at least one processor stores the encoded representation of the service metadata in the initialized read-only data segment of the executable file and stores the executable file itself in the memory. By storing the encoded representation of the service metadata (rather than the actual service metadata) in the memory, the device provided in the first aspect can reduce the disk footprint of the executable file and reduce the amount of service metadata loaded during application runtime, compared to traditional AOT compilers.

[0009] In an embodiment of the first aspect, the uninitialized data segment of the executable file includes a Block Started by Symbol (BSS) segment. This can achieve compatibility of the apparatus provided by the first aspect with a public standard file format for executable files.

[0010] In an embodiment of the first aspect, the at least one processor is configured to determine the service metadata of the application by parsing the source code of the application. This can make the apparatus provided by the second aspect more flexible.

[0011] In one embodiment of the first aspect, the memory is further configured to store a database comprising a plurality of source codes and service metadata corresponding to different applications. In this embodiment, the at least one processor is configured to determine the service metadata of the application by accessing the database, searching the database for the source code of the application, and reading the service metadata of the application from the database. Using such a database can expedite the acquisition of service metadata without having to analyze (e.g., parse) the source code of the application, thereby reducing computational costs.

[0012] In one embodiment of the first aspect, the at least one processor is configured to obtain the encoded representation of the service metadata based on at least one of the following: a type of the service metadata, a required size of the encoded representation of the service metadata, and a required decoding time of the encoded representation of the service metadata. This allows for obtaining a compact and quickly decoded encoded representation of the service metadata, thereby more efficiently reducing the disk footprint of executable files and application startup time. Furthermore, reducing application startup time can improve application runtime performance.

[0013] In one embodiment of the first aspect, the at least one processor is further configured to select a required size of the encoded representation of the service metadata based on a pre-allocated size of the memory to be used for storing the executable file. This can more efficiently utilize memory in the apparatus provided by the first aspect.

[0014] In an embodiment of the first aspect, the at least one processor is further configured to select the required decoding time according to a predefined startup time of the application, so as to decode the service metadata more efficiently.

[0015] In one embodiment of the first aspect, the at least one processor is configured to obtain the encoded representation of the service metadata using a common data compression algorithm. Common data compression algorithms (e.g., variable length coding, Little Endian Base 128 (LEB128) coding, Huffman coding, Lempel-Ziv-Markov chain algorithm (LZMA) coding, run-length coding, etc.) can more efficiently compress the service metadata into the encoded representation.

[0016] In an embodiment of the first aspect, the at least one processor is configured to compile the source code using an AOT compiler, which can make the apparatus provided by the second aspect more flexible.

[0017] According to a second aspect, a device for initializing service metadata for an application is provided. The device provided in the second aspect includes at least one processor and a memory coupled to the at least one processor. The memory is used to store processor-executable instructions, which cause the at least one processor to operate as follows. First, the at least one processor accesses an executable file for the application. The executable file includes an initialized read-only data segment and an uninitialized data segment. The initialized read-only data segment of the executable file includes an encoded representation of the service metadata for the application. The uninitialized data segment of the executable file is at least partially reserved for the service metadata. Then, the at least one processor obtains a decoded representation of the service metadata by decoding the encoded representation of the service metadata. Thereafter, the at least one processor initializes the service metadata based on the decoded representation of the service metadata in the reserved uninitialized data segment of the executable file. By using the executable file configured in this manner, the device provided in the second aspect can correctly and quickly initialize the actual service metadata required to run and operate the application, thereby significantly reducing application startup time.

[0018] In an embodiment of the second aspect, the uninitialized data segment of the executable file includes a block segment starting with a symbol. This can achieve compatibility of the apparatus provided by the second aspect with a public standard file format for executable files.

[0019] In one embodiment of the second aspect, the at least one processor is configured to decode the encoded representation of the service metadata using a general-purpose data decompression algorithm. General-purpose data decompression algorithms (e.g., variable length decoding, LEB128 decoding, Huffman decoding, LZMA decoding, run-length decoding, etc.) can improve the efficiency of obtaining the decoded representation of the service metadata.

[0020] According to a third aspect, a device for running an application is provided. The device provided by the third aspect includes the device provided by the first aspect and the device provided by the second aspect. With this configuration, the device provided by the third aspect can perform the functions of encoding and initializing service metadata, while providing the same advantages as discussed above in conjunction with the devices provided by the first and second aspects.

[0021] According to a fourth aspect, a method for encoding service metadata for an application is provided. The method provided by the fourth aspect begins by receiving source code for the application and using the source code to determine the service metadata for the application. The method provided by the fourth aspect then proceeds to obtaining an encoded representation of the service metadata. Thereafter, the method provided by the fourth aspect proceeds to compiling the source code to generate an executable file for the application. The executable file includes an initialized read-only data segment and an uninitialized data segment. Furthermore, the method provided by the fourth aspect continues by reserving at least partially the uninitialized data segment of the executable file for the service metadata and storing the encoded representation of the service metadata in the initialized read-only data segment of the executable file. The method provided by the fourth aspect concludes by storing the executable file itself. By storing the encoded representation of the service metadata (rather than the actual service metadata) in memory, the disk footprint of the executable file can be reduced compared to traditional AOT compilation, while also reducing the amount of service metadata loaded during application runtime.

[0022] According to the fifth aspect, a method for initializing the service metadata of an application is provided. The method provided by the fifth aspect starts with the following steps: accessing the executable file of the application. The executable file includes an initialized read-only data segment and an uninitialized data segment. The initialized read-only data segment of the executable file includes an encoded representation of the service metadata of the application, and the uninitialized data segment of the executable file is at least partially reserved for the service metadata. Then, the method provided by the fifth aspect continues with the following steps: obtaining a decoded representation of the service metadata by decoding the encoded representation of the service metadata. The method provided by the fifth aspect ends with the following steps: initializing the service metadata based on the decoded representation of the service metadata in the reserved uninitialized data segment of the executable file. Using the executable file configured in this way, the actual service metadata required to run and operate the application can be initialized correctly and quickly, thereby significantly reducing the application startup time.

[0023] According to a sixth aspect, a computer program product is provided. The computer program product provided in the sixth aspect stores a computer-readable storage medium including computer code. When the computer code is executed by at least one processor, the at least one processor is caused to perform the method provided in the fourth aspect. Using such a computer program product can simplify the implementation of the method provided in the fourth aspect in any computing device (e.g., the apparatus provided in the first aspect).

[0024] According to a seventh aspect, a computer program product is provided. The computer program product provided in the seventh aspect stores a computer-readable storage medium including computer code. When the computer code is executed by at least one processor, the at least one processor is caused to perform the method provided in the fifth aspect. Using such a computer program product can simplify the implementation of the method provided in the fifth aspect in any computing device (e.g., the apparatus provided in the second aspect).

[0025] Other features and advantages of the present invention will be apparent from a reading of the following detailed description and a review of the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The present invention will be explained below with reference to the accompanying drawings, in which:

[0027] Figure 1 is a block diagram of an apparatus for encoding service metadata of an application provided by an exemplary embodiment;

[0028] Figure 2 is a flowchart of a method for encoding service metadata of an application provided by an exemplary embodiment;

[0029] Figure 3 is a block diagram of an apparatus for initializing service metadata of an application provided by an exemplary embodiment;

[0030] Figure 4 is a flowchart of a method for initializing service metadata of an application provided by an exemplary embodiment;

[0031] Figure 5 is a block diagram of an apparatus for running an application provided by an exemplary embodiment;

[0032] Figure 6 is a bar graph showing the total size reduction (in kilobytes) of the encoded representation of the VMT layout in different Java runtime environments;

[0033] Figure 7 is a bar graph showing the total size reduction (in kilobytes) of the entire executable file in the same Java runtime environment. DETAILED DESCRIPTION

[0034] Various embodiments of the present invention are further described in detail with reference to the accompanying drawings. However, the present invention may be embodied in many other forms and should not be construed as limited to any specific structure or function discussed in the following description. Rather, these embodiments are provided to make the description of the present invention detailed and complete.

[0035] It will be apparent to those skilled in the art that the scope of the present invention encompasses any embodiment of the present invention disclosed herein, regardless of whether the embodiment is implemented independently or in conjunction with any other embodiment of the present invention. For example, the devices and methods disclosed herein can be implemented using any number of the embodiments provided herein. Furthermore, it should be understood that any embodiment of the present invention can be implemented using one or more of the elements set forth in the appended claims.

[0036] The word “exemplary” is used herein to mean “serving as an illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments unless otherwise stated.

[0037] According to the embodiments disclosed herein, user equipment (UE) may refer to a mobile device, a mobile station, a mobile terminal, a subscriber unit, a mobile phone, a cellular phone, a smart phone, a cordless phone, a personal digital assistant (PDA), a wireless communication device, a desktop computer, a laptop computer, a tablet computer, a gaming device (e.g., a game console, a game controller, etc.), a netbook, a smartbook, an ultrabook, a medical device or medical equipment, a biometric sensor, a wearable device (e.g., a smart watch, smart glasses, a smart wristband, etc.), an entertainment device (e.g., an audio player, a video player, etc.), an in-vehicle component or sensor, a smart meter / sensor, an unmanned vehicle (e.g., an industrial robot, a quadcopter, etc.), an industrial manufacturing equipment, a global positioning system (GPS) device, an Internet of Things (IoT) device, a machine-type communication (MTC) device, a group of massive IoT (MIoT) or massive MTC (mMTC) devices / sensors, or any other suitable device for supporting wireless or wired communication. In some exemplary embodiments, a UE may refer to at least two collocated and interconnected UEs as defined above.

[0038] The application program or simply application used in the embodiments disclosed herein may refer to a software program running on a UE. Some examples of applications include web browsers, email programs, word processors, spreadsheets, games, utilities, and the like. In general, the term "application" may include any program that performs a specific function on a UE. It is also intended herein that an application be stored in and implemented by one or more executable files. Such an executable file may include an initialized data segment and an uninitialized data segment. The uninitialized data segment includes all global variables and static variables that are initialized to 0 or are not explicitly initialized in the source code of the application. In contrast, the initialized data segment includes uninitialized static variables and global variables in the source code of the application. The initialized data segment is further divided into a data segment and a read-only data (rodata) segment. The rodata segment typically stores all read-only global and static variables, while the data segment is read-write, meaning that the variables stored therein can be changed during the runtime of the application.

[0039] According to the embodiments disclosed herein, service metadata may refer to runtime data and structures required for efficient application execution (e.g., Virtual Method Table (VMT), Interface Method Table (IMT), class instance layout information for the Garbage Collector (GC), etc.). Service metadata is typically generated by a compiler based on the application's source code and later used when the application is running. Service metadata often includes direct references to other data structures (which are efficient at runtime). These direct references may be updated at load time (i.e., when the application is first loaded and executed by the UE's operating system) and are therefore not easily compressed.

[0040] There are at least two existing methods for generating service metadata: AOT compilation and JIT compilation. AOT compilation involves generating all the service metadata required by an application in advance and then storing this service metadata in the application's executable file. Therefore, AOT compilation increases the disk footprint of the executable file and slows down application startup due to the relatively large amount of service metadata to be loaded. In contrast, JIT compilation involves generating all service metadata just in time (i.e., when the application starts). JIT compilation can be used together with AOT compilation. Although JIT compilation eliminates the disk footprint overhead unique to AOT compilation, it increases the startup time and execution time of the application. In addition, if used together with AOT compilation, JIT compilation will also have a certain impact on the optimization capabilities of traditional AOT compilers. Generally speaking, these methods all perform service metadata generation as a separate continuous process, thereby generating all necessary service metadata at compile time (AOT) or runtime (JIT).

[0041] The exemplary embodiments disclosed herein provide a technical solution that reduces or even eliminates the above-mentioned shortcomings specific to the prior art. Specifically, the technical solution disclosed herein includes obtaining an encoded representation of the service metadata and storing it in an initialized read-only data segment of the executable file of the application, and reserving at least partially the uninitialized data segment of the executable file for the service metadata itself. The encoded representation is then decoded during the runtime of the application to initialize the service metadata in the retained uninitialized data segment. This can reduce the disk footprint of the application (executable file size) because only the encoded representation of the service metadata is stored in the executable file, rather than the actual service metadata being stored in the executable file. In addition, the encoded representation of the service metadata can be decoded quickly, thereby reducing the startup time of the application.

[0042] Figure 1 FIG1 is a block diagram of an apparatus 100 for encoding service metadata of an application provided by an exemplary embodiment. The apparatus 100 may be a part of a UE, or implemented as a separate apparatus (e.g., a remote server) that can be accessed by the UE via a wireless connection or a wired connection. Figure 1 As shown, the apparatus 100 includes a processor 102 and a memory 104. The memory 104 stores processor-executable instructions 106, which, when executed by the processor 102, cause the processor 102 to compress the service metadata of the application into their encoded representations, as described in detail below. Figure 1 The number, arrangement, and interconnection of the structural elements constituting the device 100 shown in the figure are not intended to limit the present invention, but are merely intended to provide a general idea of ​​how the structural elements are implemented within the device 100. For example, the processor 102 can be replaced by several processors, and the memory 104 can be replaced by several removable and / or fixed storage devices, depending on the specific application. In addition, if the device 100 is implemented separately, it can also include a transceiver for performing data reception and transmission for different purposes. In some embodiments, such a transceiver can be implemented as two separate devices, one of which is used for receiving operations and the other for transmitting operations. Regardless of how it is implemented, the transceiver is capable of performing the different operations required for data reception and transmission, such as signal modulation / demodulation, encoding / decoding, etc.

[0043] The processor 102 may be implemented as a CPU, a general-purpose processor, a special-purpose processor, a microcontroller, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a complex programmable logic device, etc. It should also be noted that the processor 102 may be implemented as any combination of one or more of the above. For example, the processor 102 may be a combination of two or more microprocessors.

[0044] The memory 104 can be implemented as a classic non-volatile memory or volatile memory used in modern electronic computers. For example, non-volatile memory can include read-only memory (ROM), ferroelectric random-access memory (RAM), programmable ROM (PROM), electrically erasable PROM (EEPROM), solid state drive (SSD), flash memory, magnetic disk storage (such as hard disk drive and magnetic tape), optical disk storage (such as CD, DVD and Blu-ray disc), etc. Examples of volatile memory include dynamic RAM, synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), static RAM, etc.

[0045] The processor-executable instructions 106 stored in the memory 104 can be configured to cause the processor 102 to execute computer-executable code for various aspects of the present invention. The computer-executable code for performing the operations or steps of various aspects of the present invention can be written in any combination of one or more programming languages ​​(e.g., Java, C++, etc.). In some examples, the computer-executable code can be in the form of a high-level language or in a pre-compiled form and dynamically generated by an interpreter (also pre-stored in the memory 104).

[0046] Figure 2The flowchart of a method 200 for encoding service metadata for an application, provided by an exemplary embodiment, is shown. Generally speaking, method 200 describes the operation of apparatus 100. Method 200 begins at step S202, where processor 102 receives source code for an application. The source code can be written in any object-oriented programming language (e.g., Java, C++, C#, Python, R, PHP, JavaScript, Ruby, Perl, Object Pascal, etc.). The source code can be provided to processor 102 externally (e.g., by an application provider) or written by a user of apparatus 100 using any suitable programming software. Method 200 then proceeds to step S204, where processor 102 uses the source code to determine the service metadata for the application. Thereafter, step S206 is executed, where processor 102 obtains an encoded representation of the service metadata. Next, method 200 proceeds to step S208, where processor 102 compiles the source code to generate an executable file for the application. Step S208 can be performed by a conventional AOT compiler; however, this should not be construed as limiting the present invention; any other suitable compiler can be used for the same purpose. The executable file includes an initialized read-only data (rodata) segment and an uninitialized data segment. Furthermore, method 200 proceeds to step S210, where processor 102 reserves at least a portion of the uninitialized data segment of the executable file for service metadata, and then proceeds to step S212, where processor 102 stores an encoded representation of the service metadata in the initialized read-only data segment of the executable file. Method 200 concludes at step S214, where processor 102 stores the executable file itself in memory 104 of device 100.

[0047] In one exemplary embodiment, the uninitialized data segment of the executable file includes a Block Started by Symbol (BSS) segment. This can achieve compatibility between the apparatus provided by the first aspect and a common standard file format for executable files (e.g., Executable and Linkable Format (ELF), which is a common file format for executable files in Linux systems). In another exemplary embodiment, the uninitialized data segment of the executable file can be configured as part of the initialized data segment; however, this possible embodiment is less efficient than the previous embodiment (i.e., using the BSS segment) because it wastes space in the executable file and may slow down application startup.

[0048] In an exemplary embodiment, the processor 102 is configured to determine the service metadata of the application in step S204 of the method 200 by parsing the source code of the application. In addition to parsing, the processor 102 may also use any other suitable source code analysis tool to determine the service metadata.

[0049] In another exemplary embodiment, memory 104 is further configured to store a database including multiple source codes and service metadata corresponding to different applications. In this embodiment, processor 102 is configured to determine the service metadata of the application in step S204 of method 200 by accessing the database, searching the database for the source code of the application, and reading the service metadata of the application from the database. The database itself can be configured in a tabular format. The database can be configured such that each row corresponds to a specific source code, and each column includes a service metadata component corresponding to the source code. Alternatively, the database can be configured as a set of tables, each of which is associated with a specific source code and includes service metadata for the source code. Processor 102 can be configured to query and maintain the database using any suitable programming language (e.g., Structured Query Language (SQL)). Using such a database can expedite the acquisition of service metadata without having to analyze (e.g., parse) the source code of the application, thereby reducing computational costs.

[0050] In an exemplary embodiment, processor 102 is configured to obtain an encoded representation of the service metadata in step S206 of method 200 based on at least one of the following: the type of the service metadata, a desired size of the encoded representation of the service metadata, and a desired decoding time of the encoded representation of the service metadata. The desired size of the encoded representation of the service metadata may be selected based on a pre-allocated size of memory to store the executable file. The desired decoding time may be selected based on a predefined startup time of the application. This allows for a compact and quickly decoded encoded representation of the service metadata, thereby more efficiently reducing the executable file's disk footprint and application startup time.

[0051] The processor 102 may use a general data compression algorithm to obtain the encoded representation of the service metadata. Examples of general data compression algorithms include, but are not limited to, variable length coding, Little Endian Base 128 (LEB128) coding, Huffman coding, Lempel-Ziv-Markov chain algorithm (LZMA) coding, run-length coding, etc. General data compression algorithms can more efficiently compress the service metadata into an encoded representation.

[0052] Figure 3 FIG3 is a block diagram of an apparatus 300 for initializing service metadata of an application provided by an exemplary embodiment. The apparatus 300 may be a part of the same UE as the apparatus 100, or may be implemented as a separate apparatus for communicating with the apparatus 100 via a wireless connection or a wired connection. Figure 3 As shown, the apparatus 300 includes a processor 302 and a memory 304. The memory 304 stores processor executable instructions 306. When the processor executable instructions 306 are executed by the processor 302, the processor 302 initializes the service metadata of the application, as described in detail below. Figure 3 The number, arrangement, and interconnection of the structural elements constituting the device 300 shown in the figure are not intended to limit the present invention, but are merely intended to provide a general idea of ​​how the structural elements are implemented within the device 300. For example, the processor 302 can be replaced by several processors, and the memory 304 can be replaced by several removable and / or fixed storage devices, depending on the specific application. In addition, if the device 300 is implemented separately, it can also include a transceiver for performing data reception and transmission for different purposes. In some embodiments, such a transceiver can be implemented as two separate devices, one of which is used for receiving operations and the other for transmitting operations. Regardless of the implementation, the transceiver is capable of performing the different operations required for data reception and transmission, such as signal modulation / demodulation, encoding / decoding, etc.

[0053] Generally speaking, the processor 302 , the memory 304 , and the executable instructions 306 may be implemented in the same or similar manner as the processor 102 , the memory 104 , and the executable instructions 106 , respectively, in the apparatus 100 .

[0054] Figure 44 is a flow chart of a method 400 for initializing service metadata for an application, provided by an exemplary embodiment. Generally speaking, method 400 describes the operation of apparatus 300. Method 400 begins at step S402, where processor 302 accesses the executable file of the application stored in memory 104 of apparatus 100 in step S214 of method 200. If apparatus 100 and apparatus 300 are implemented in the same UE, accessing the executable file in step S402 of method 400 includes loading or reading the executable file from memory 104 of apparatus 100. Meanwhile, if apparatus 300 is implemented remotely from apparatus 100, processor 302 may access the executable file by communicating with apparatus 100 (via a wired or wireless connection) to download the executable file from memory 104. As described above, the executable file includes an encoded representation of the service metadata in its initialized read-only data segment, while its uninitialized data segment (e.g., the BSS segment) is at least partially reserved for the service metadata. Method 400 then proceeds to step S404, where processor 302 decodes the encoded representation of the service metadata to obtain a decoded representation of the service metadata. Step S404 may be performed by processor 302 using a common data decompression algorithm. Examples of common data decompression algorithms include, but are not limited to, variable length decoding, LEB128 decoding, Huffman decoding, LZMA decoding, run-length decoding, and the like. Method 400 concludes at step S406, where processor 302 initializes the service metadata using the decoded representation of the service metadata in the reserved, uninitialized data segment of the executable file.

[0055] Figure 5 FIG. 5 is a block diagram of an apparatus 500 for running an application provided by an exemplary embodiment. The apparatus 500 can be implemented as any UE discussed above. Figure 5 As shown, the apparatus 500 includes the apparatus 100 and the apparatus 300. With this configuration, the apparatus 500 can perform the functions of encoding and initializing service metadata while providing the same advantages as those discussed above in conjunction with the apparatus 100 and the apparatus 300.

[0056] The following examples illustrate how the aforementioned apparatuses 100 and 300 operate together, or how apparatus 500 operates. Specifically, it is assumed that the service metadata of an application is represented by the Virtual Method Table (VMT), the largest service metadata structure in object-oriented programming. The VMT itself is an array of method code references associated with each class, directly accessible from every object of a given class. The VMT has a hierarchical structure: subclasses inherit the VMT layout of their superclasses, while adding new entries and / or overwriting entries of overridden methods with new implementation addresses. During compilation, processor 102, using a suitable compiler (e.g., an AOT compiler), assigns a unique index, called a virtual number or vnum, to each method when declaring the VMT for a class. The compiler then uses this virtual number to efficiently generate virtual calls, which are indirect calls implemented through the VMT with that virtual number. It should also be noted that the present invention is not limited to the VMT; methods 200 and 300 can also be applied to other service metadata structures, such as the Interface Method Table (IMT).

[0057] The method 200 is used below to generate a VMT for an exemplary class hierarchy in any object-oriented language (e.g., Java, C#, etc.), as follows:

[0058]

[0059] The above hierarchy includes two classes B and C. Class C extends class B, overrides method "a" defined in B with its own implementation, and defines method "e". Methods "b", "c", and "d" are already defined in B. When the application is run, the final VMT structure of the hierarchy is as follows:

[0060]

[0061] In this case, method 200 can be performed as follows. First, in steps S202 and S204, the processor 102 receives the source code of the class defined in the application and uses the AOT compiler to parse the source code to determine the service metadata of the class. The service metadata is presented as the VMT layout of the class. This layout may be as simple as an internal representation array of the method, thereby mirroring the addresses in the final VMT structure, provided that the hierarchical properties of the VMT are retained. Then, in step S206, the processor 102 encodes the VMT layout into a compact encoding representation. In order to completely rebuild the above-mentioned VMT at runtime of the application, it is sufficient as long as there is a difference in the VMT layout between class C and its superclass B. This difference can be encoded as a series of single-parameter instructions, as shown in Table 1 below, where "methodID" is a unique identifier of the method implementation (which can be global, class-based, package-based, etc.).

[0062] Table 1: VMT encoded instructions

[0063]

[0064] Each instruction in Table 1 is represented as an integer, where the least significant bit is used to distinguish between the two given instructions (i.e., "Put" and "Skip"), and the remaining bits represent the instruction parameters. These integers are also encoded using a variable-length encoding (e.g., LEB128). It should be noted that in step S212, the final encoded binary data (blob) (i.e., the encoded representation of the service metadata) is stored in the initialized read-only data segment of the executable file.

[0065] A possible procedure for encoding the VMT layout of class C described above can be presented as the following pseudocode (similar pseudocode can also be written for superclass B):

[0066] 1. Initialize the variable "skipAmount" to 0;

[0067] 2. For each entry in C's VMT layout:

[0068] a. If the item inherits from the superclass layout (has the same method implementation), then the variable

[0069] "skipAmount" plus 1;

[0070] b. Otherwise, if the variable "skipAmount" is greater than 0, a "Skip(skipAmount)" instruction is issued, and a "Put(id(m))" instruction is issued, where "id(m)" is the "methodID" of the method in the entry;

[0071] 3. Write the number of instructions issued to the metadata.

[0072] Thus, the final encoded representation of the VMT layout for superclass B in the exemplary class hierarchy above includes four "Put" instructions, with a "methodID" for each entry in the VMT layout for superclass B. Conversely, the final encoded representation of the VMT layout for class C includes the following instructions:

[0073]

[0074] Once the encoded representation of the VMT layout for all categories is obtained, the processor 102 compiles the source code in step S208 to generate an executable file, and in step S210, the uninitialized data segment of the executable file is at least partially reserved for the service metadata (i.e., the VMT itself). In other words, the processor 102 allocates uninitialized space for the VMT in the executable file, and the address of the VMT is used directly in the source code to initialize the newly created object of the VMT category. This space can be allocated in the BSS segment, which is represented as a single integer in the executable file, i.e., the total size of the segment (in bytes). Therefore, allocation simply increases the BSS segment size by the VMT size. In the exemplary class hierarchy above, the VMT sizes of class B and class C are 4 addresses and 5 addresses, respectively (assuming a 32-bit architecture, the address size is 4 bytes, so the VMT sizes are 16 bytes and 20 bytes).

[0075] When the encoded representation of the VMT layout for all categories is obtained and stored in the initialized read-only data segment of the executable file, and the uninitialized data segment of the executable file is at least partially reserved for the VMT itself, the processor 102 stores the executable file in the memory 104 in the last step S214 of the method 200.

[0076] When the application is started, the method 400 may be executed as follows. In step S402, the processor 302 accesses the executable file stored in the memory 104 and reads or downloads the encoded representation of the VMT layout for each category. Then, in step S404, the processor 302 decodes the encoded representation and uses the encoded representation to initialize the VMT structure in step S406. The entire initialization of the VMT structure can be presented as the following pseudo code:

[0077] 1. Perform the startup initialization steps for the VMT of superclass B;

[0078] 2. Copy the initialized VMT of superclass B to the VMT of this class located in the BSS segment;

[0079] 3. Initialize the variable "slot" to 0;

[0080] 4. For each decoded instruction:

[0081] a. If the instruction is "Put(id)", the address of the method with "id" is stored in the "slot" of the VMT

[0082] In the entry;

[0083] b. Otherwise, the instruction is "Skip(skipAmount)", so add "skipAmount" to "slot".

[0084] To demonstrate the efficiency of methods 200 and 400, respectively, performed by apparatus 100 and apparatus 300, namely, significantly reducing the disk footprint of executable files and application startup time, tests were conducted on various applications and libraries written in several Java Virtual Machine (JVM)-based languages ​​and ultimately executed on a JVM (or Java Runtime Environment (JRE)) that supports AOT compilation. Specifically, the following applications and libraries were used during testing:

[0085] -jre1.8.0_212(cp1), which is the standard library and runtime environment for Java SE 8 (written in Java),

[0086] With compact profile 1;

[0087] scala-2.13.0, the standard library for the Scala programming language (written in Scala);

[0088] KotlinC-1.1.0, a compiler for the Kotlin programming language (written in Kotlin);

[0089] -jruby-9.1.8.0, an implementation of the Ruby programming language for the JVM (written in Ruby and Java).

[0090] All of these applications and libraries are compiled ahead of time and evaluated based on the total size of the encoded representation of the VMT layout and the IMT layout and the total size of the executable file (in KB).

[0091] Specifically, Figure 62 is a bar graph showing the total size reduction of the encoded representation for the VMT layout and the IMT layout. The final size of the encoded representation for the VMT layout and the IMT layout (i.e., service metadata) is shown in the solid portion of each bar, while the size reduction provided by method 200 is shown in the hollow portion of the bar. As can be seen, the total size reduction of the encoded representation is very significant in all cases (over 50% in all tests, and as high as 97% in some tests).

[0092] Figure 7 is a bar chart showing the total size reduction of the executable file. Similarly, the final size of the executable file is shown as the solid portion of each bar, while the size reduction provided by method 200 is shown as the hollow portion of the bar. The executable size reduction in three of the cases (i.e., scala-2.13.0, KotlinC-1.1.0, and jruby-9.1.8.0) is substantial, but is considered very feasible, especially for embedded or resource-constrained devices.

[0093] It should be noted that each step or operation of method 200 and method 300, or any combination of steps or operations, can be implemented in various ways, such as hardware, firmware, and / or software. For example, one or more of the steps or operations described above can be embodied via processor-executable instructions, data structures, program modules, and other suitable data representations. Furthermore, the executable instructions embodying the steps or operations described above can be stored on a corresponding data carrier and executed by processor 102 and processor 302. The data carrier can be implemented as any computer-readable storage medium for being read by at least one processor to execute computer-executable instructions. Such computer-readable storage media can include volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media include media implemented using any method or technology suitable for storing information. More specifically, practical examples of computer-readable media include, but are not limited to, information transfer media, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVDs), holographic media or other optical disk storage, magnetic tape, cassettes, magnetic disk storage, and other magnetic storage devices.

[0094] Although exemplary embodiments of the invention have been described herein, it should be noted that various changes and modifications may be made in the embodiments of the invention without departing from the scope of legal protection as defined by the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere recitation of certain measures in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A device for encoding service metadata of an application, characterized in that The device comprises: at least one processor; a memory coupled to the at least one processor and configured to store processor-executable instructions, wherein: The at least one processor, when executing the processor-executable instructions, is configured to: receiving source code of the application; determining the service metadata of the application according to the source code; Obtaining an encoded representation of the service metadata by using a common data compression algorithm; Compiling the source code to generate an executable file of the application, wherein the executable file includes an initialized read-only data segment and an uninitialized data segment; reserving, at least in part, the uninitialized data segment of the executable file to the service metadata; storing the encoded representation of the service metadata in the initialized read-only data segment of the executable file so as to decode the encoded representation during runtime of the application, and initializing the service metadata in the reserved uninitialized data segment; The executable file is stored in the memory.

2. The device according to claim 1, characterized in that The uninitialized data segment of the executable file includes a block segment starting with a symbol.

3. The device according to claim 1 or 2, characterized in that The at least one processor is configured to determine the service metadata of the application by parsing the source code of the application.

4. The device according to claim 1 or 2, characterized in that The memory is also used to store a database including multiple source codes and service metadata corresponding to different applications, and the at least one processor is used to determine the service metadata of the application by accessing the database, searching for the source code of the application in the database, and reading the service metadata of the application from the database.

5. The device according to claim 1, characterized in that The at least one processor is configured to obtain the encoded representation of the service metadata according to at least one of the following: The type of the service metadata; a required size of the encoded representation of the service metadata; A required decoding time of the encoded representation of the service metadata.

6. The device according to claim 5, characterized in that The at least one processor is further configured to select a desired size of the encoded representation of the service metadata based on a pre-allocated size of the memory to be used for storing the executable file.

7. The device according to claim 5 or 6, characterized in that The at least one processor is further configured to select the required decoding time based on a predefined startup time of the application.

8. The device according to claim 1, characterized in that The at least one processor is configured to obtain the encoded representation of the service metadata using a common data compression algorithm.

9. A device for initializing service metadata of an application, characterized in that: The device comprises: at least one processor; a memory coupled to the at least one processor and configured to store processor-executable instructions, wherein: The at least one processor, when executing the processor-executable instructions, is configured to: accessing an executable file of the application, wherein the executable file includes an initialized read-only data segment and an uninitialized data segment, the initialized read-only data segment of the executable file includes an encoded representation of the service metadata of the application, and the uninitialized data segment of the executable file is at least partially reserved for the service metadata; the encoded representation of the service metadata is obtained by using a common data compression algorithm; Obtaining a decoded representation of the service metadata by decoding the encoded representation of the service metadata; The service metadata is initialized based on the decoded representation of the service metadata in the reserved uninitialized data segment of the executable file.

10. The device according to claim 9, characterized in that The uninitialized data segment of the executable file includes a block segment starting with a symbol.

11. The device according to claim 9 or 10, characterized in that The at least one processor is configured to decode the encoded representation of the service metadata using a common data decompression algorithm.

12. A device for running an application, characterized in that: The device comprises: The device according to any one of claims 1 to 8; A device according to any one of claims 9 to 11.

13. A method for encoding service metadata of an application, characterized in that The method comprises: receiving source code of the application; determining the service metadata of the application according to the source code; Obtaining an encoded representation of the service metadata by using a common data compression algorithm; Compiling the source code to generate an executable file of the application, wherein the executable file includes an initialized read-only data segment and an uninitialized data segment; reserving, at least in part, the uninitialized data segment of the executable file to the service metadata; storing the encoded representation of the service metadata in the initialized read-only data segment of the executable file so as to decode the encoded representation during runtime of the application, and initializing the service metadata in the reserved uninitialized data segment; The executable file is stored.

14. A method for initializing service metadata of an application, characterized in that: The method comprises: accessing an executable file of the application, wherein the executable file includes an initialized read-only data segment and an uninitialized data segment, the initialized read-only data segment of the executable file includes an encoded representation of the service metadata of the application, and the uninitialized data segment of the executable file is at least partially reserved for the service metadata; the encoded representation of the service metadata is obtained by using a common data compression algorithm; Obtaining a decoded representation of the service metadata by decoding the encoded representation of the service metadata; The service metadata is initialized based on the decoded representation of the service metadata in the reserved uninitialized data segment of the executable file.

15. A computer program product stored on a computer-readable storage medium, characterized in that: The computer readable storage medium comprises computer code which, when executed by at least one processor, causes the at least one processor to perform the method according to claim 13 .

16. A computer program product stored on a computer-readable storage medium, characterized in that The computer readable storage medium comprises computer code which, when executed by at least one processor, causes the at least one processor to perform the method according to claim 14 .

Images