A cross-language compilation method and device
By converting local and non-native language codes in hybrid programming into intermediate languages and generating optimized calling methods, the call overhead problem caused by invisibility of local and non-native language codes is solved, and more efficient hybrid programming is achieved performance.
Patent Information
- Application Number
- CN201910228528.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2019-03-25
- Publication Date
- 2025-02-21
- Estimated Expiration
- 2039-03-25
AI Technical Summary
In hybrid programming, since the local language and non-native language codes are invisible to each other, cross-function compilation optimization can only be carried out within the scope of the same language function, adding to the mutual call between local language and non-native language methods at runtime Overhead.
By converting local and non-native language code into intermediate languages, generating call methods in intermediate languages, optimizing call methods between local and non-native languages, and reducing runtime call overhead.
Through the optimization of intermediate languages, the overhead of calling each other at runtime between local and non-native language methods is reduced, and the efficiency and performance of hybrid programming is improved.
Smart Images

Figure CN111736838B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to computer code compilation technology, and in particular to a cross-language hybrid compilation technology. Background Art
[0002] In order to balance development efficiency and program performance, mixed programming of native languages and non-native languages has become a trend. For example, non-native languages such as Java, JavaScript, and Python all support mixed programming with C / C++. When compiling the source code of mixed programming, the native language code and non-native language code are not visible to each other during the compilation process. In this case, cross-function compilation optimization can only be performed within the scope of the same language function. In the Java Virtual Machine (JVM), Java programs are compiled into bytecodes that are independent of the machine and operating system. C / C++ programs are compiled into binary executable programs related to the target machine. During the compilation phase, Java programs and C / C++ programs are not visible to each other. During the execution phase, Java bytecodes are first interpreted and executed by an interpreter. When the number of times the same section of code is executed reaches a certain threshold, it will be compiled into machine-related binary code, and then the compiled binary code will be executed.
[0003] In hybrid programming, in order to implement function calls between native languages and non-native languages, Java functions call C / C++ functions through JNI, and C / C++ functions call Java code and access Java objects / Java class objects through reflection mechanisms. Due to the need to be compatible with different VMs and the mutual invisibility of Java code and C / C++ code, both the Java Native Interface (JNI) and the reflection mechanism must be implemented in the most conservative way. Therefore, the overhead of JNI and the reflection mechanism is huge. Summary of the invention
[0004] The present application provides a compilation method and device to reduce the overhead of mutual calls between native language and non-native language methods of a compiled executable program during runtime.
[0005] In a first aspect, the present application provides a compilation method, the method comprising: obtaining source program code, the source program code comprising a first language code and a second language code, the first language code comprising a first method, the second language code comprising a second method, wherein the first language code is a local language, and the second language code is a non-local language. Generating a third language code according to the source program code, the third language code comprising a third method and a fourth method, the third method being generated according to the first method, the fourth method being generated according to the second method, the third language code further comprising a fifth method, the fifth method being generated according to the first method and the second method or according to the third method and the fourth method, the fifth method being used for the third method to call the fourth method through the fifth method or the fourth method to call the third method through the fifth method.
[0006] The third method may be an intermediate language, that is, converting the source code containing the native language and the non-native language into the same intermediate language. The intermediate language contains methods that can be used to call each other between the methods corresponding to the native language and the non-native language. Since the compiler can simultaneously obtain the method information of the native language and the non-native language through the intermediate language, when generating the calling method between the native language and the non-native language, the calling method can be optimized according to the method information of the native language and the non-native language, thereby reducing the overhead of calling each other between the native language and the non-native language methods at runtime.
[0007] In some implementations, the intermediate language method will have a function attribute identifier, which is used to indicate whether the intermediate language method is converted from the native language or from the non-native language. This identifier can be used to quickly unload the stack when an exception occurs during the running process.
[0008] In some implementations, the calling method in the intermediate language is used to combine the method converted from the non-native language with the method converted from the native language at runtime to jointly complete the call between the method converted from the non-native language and the method converted from the native language.
[0009] In other implementations, when generating a calling method in an intermediate language, the method converted from the non-native language and the method converted from the native language can be integrated into the calling method in an inline manner, so that at runtime, the calling method can independently implement mutual calls between the method converted from the non-native language and the method converted from the native language.
[0010] When the fifth method in the third language code is generated, the fifth method in the third language code may be optimized based on the first language code, the second language code or the generated third language code.
[0011] In one implementation, when generating the fifth method, it is determined whether the first method or the third method will have an exception. If so, a fifth method is generated for the fourth method to call the third method, and the fifth method includes an exception handling function. Compared with the prior art, when calling a native language method, it is necessary to call an exception handling function at runtime to check whether there is an unhandled exception object. This implementation method generates a calling function at the compile stage, and only includes an exception handling function when the native language generates an exception, thereby reducing the exception handling overhead at runtime.
[0012] In one implementation, it is determined whether the first method accesses an object in the second language code. If so, when generating the third language code according to the source code, an object reference table in the second language code is generated. In this implementation, when generating the intermediate code, the reference of the first method to the object in the second language code can be analyzed, the object reference table can be created as needed, and the references that are no longer used can be released in time. In this way, the overhead of creating the object reference table can be reduced.
[0013] In one implementation, it is determined whether the first method accesses a JNI interface pointer in the second language code, and if so, the JNI interface pointer is added to the parameters of the fifth method. In another implementation, it is determined whether the first method accesses a Java object or a Java class object in the second language code, and if so, the Java object or the Java class object is added to the parameters of the fifth method. Thus, the calling overhead caused by the JNI interface pointer, Java object or Java class object can be reduced.
[0014] In an implementation manner, the third language code further includes domain information of the class, method information of the class, and inheritance relationship of the class in the second language code.
[0015] Among them, a possible implementation method is to determine the signature of the second method in the second language code based on the inheritance relationship of the class and the method information of the class, the signature is used to indicate the name of the second method in the second language code and the class to which the second method belongs, and generate the fifth method based on the signature.
[0016] In some other possible implementations, a sixth method is generated in the third language code according to the inheritance relationship of the class and the domain information of the class, and the sixth method is used to access the domain in the second language code.
[0017] In some other possible implementations, data required for non-native language reflection will be generated in the third language code, including metadata information of the class, field information of the class, and method information of the class.
[0018] In some other possible implementations, when generating the third language code, an interface function table of the class can be generated. The interface function table includes a hash table and a conflict elimination table. When the program executes an interface function of the class at runtime, the hash value of the function signature is used to search in the hash table. If the function is found, the function address is returned; otherwise, the function signature is used to search in the conflict elimination table and the function address is returned. Since the calculation of the interface function table and the hash value of the function signature are completed at compile time, a variable-length hash table can be used and multiple hash functions can be tried to reduce conflicts and reduce the size of the hash table, thereby reducing memory consumption and improving virtual call performance.
[0019] In some implementations, the third method and the fourth method include an identifier, and the identifier is used to indicate that the third method is generated according to a native language or to indicate that the fourth method is generated according to a non-native language.
[0020] In the second aspect, the embodiment of the present application also provides a compilation device, which includes one or more functional units for implementing the aforementioned method steps. When the device includes multiple functional units, these functional units usually correspond to the aforementioned method steps one by one. For example, the device includes an acquisition module, which is used to obtain program source code, and the program source code includes native language code and non-native language code. A generation module, which is used to generate intermediate language code, convert the native language method and non-native language method in the source code into the intermediate language method, and is used to generate a calling method for mutual calling between the method converted by the non-native language and the method converted by the native language in the intermediate language. An optimization module, which is used to optimize the generated intermediate language. A compilation module, which is used to generate an executable binary executable program based on the analyzed and optimized intermediate language to complete the compilation process. It should be noted that the functional unit can be implemented entirely by software programs or entirely by hardware or by a combination of software and hardware.
[0021] In a third aspect, an embodiment of the present application further provides a computer system. The computer system includes at least one processor and a memory, wherein the memory is used to store a software program, and when the software program is executed by the processor, the processor of the computer system is used to execute the method of the first aspect or any one of the implementations.
[0022] In a fourth aspect, an embodiment of the present application further provides a storage medium for storing a computer program, and when the computer program is executed by a processor, the processor is used to implement any one of the methods provided in the first aspect. Specifically, the computer program may include one or more program units for implementing each step of the method.
[0023] Through the embodiment of the present application, when compiling a mixed source code containing a native language and a non-native language, the native language and the non-native language are converted into an intermediate language, and a calling method is generated according to the method calling relationship between the native language and the non-native language, for mutual calling between methods in the intermediate language. Since the compiler can simultaneously obtain method information of the native language and the non-native language through the intermediate language, when generating a calling method between the native language and the non-native language, the calling method can be optimized according to the method information of the native language and the non-native language. Compared with the prior art, the embodiment of the present application reduces the overhead of mutual calling between native language and non-native language methods at runtime. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background technology, the drawings required for use in the embodiments of the present application or the background technology will be described below.
[0025] Figure 1 This is a schematic diagram of the compilation process of source code of mixed programming, taking the mixed compilation of Java and C / C++ as an example;
[0026] Figure 2 It is a structural schematic diagram of a terminal device provided by an embodiment of the present application;
[0027] Figure 3 This is a schematic diagram of an operating environment of a Java-based operating system provided in an embodiment of the present application;
[0028] Figure 4 It is a flow chart of a method in the compilation stage provided in an embodiment of the present application;
[0029] Figure 5 It is a schematic diagram of the inheritance relationship of a class provided in an embodiment of the present application;
[0030] Figure 6 is a schematic diagram of a virtual function table of a class provided in an embodiment of the present application;
[0031] Figure 7 It is a schematic diagram of a class of interface function hash tables and conflict elimination tables provided in an embodiment of the present application;
[0032] Figure 8 It is a code example diagram provided in an embodiment of the present application;
[0033] Fig. 9 It is another code example diagram provided in the embodiment of the present application;
[0034] Fig.10 It is a flowchart of an optimization process of an intermediate language provided in an embodiment of the present application;
[0035] Fig.11 It is a flowchart of another intermediate language optimization process provided by an embodiment of the present application;
[0036] Fig.12 It is a flowchart of another intermediate language optimization process provided by an embodiment of the present application;
[0037] Fig.13 It is a logical structure diagram of a compilation system provided in an embodiment of the present application. DETAILED DESCRIPTION
[0038] In order to facilitate the understanding of the embodiments of the present application, some technical terms appearing in the embodiments of the present application are first explained.
[0039] Native Language: Also known as the local language, it refers to a communication language or code that is developed specifically for a certain type of device and is only used on the specified target device. It cannot be ported to other devices, or even if it can be ported, the work efficiency is very low. For example, C / C++ is a typical native language.
[0040] Non-native language: Also known as non-native language, it refers to a programming language that is platform-independent, that is, it can be used on a variety of different devices or platforms. Non-native languages can achieve platform universality through the operating environment. For example, JAVA is a typical non-native language.
[0041] The Java Virtual Machine (JVM) is a virtual computer component that exists only in memory. The JVM allows Java programs to be executed on different platforms, rather than just on one platform for which the code is compiled. Java programs are compiled for the JVM. In this way, Java can support applications for many types of data processing systems, which may include a variety of central processing units and operating system architectures. In order to enable Java applications to be executed on different types of data processing systems, the compiler usually generates an architecture-neutral file format-the compiled code can be executed on many processors, provided that there is a Java runtime system. The Java compiler generates bytecode instructions that are not specific to a specific computer architecture. Bytecode is a machine-independent code generated by the Java compiler and interpreted by the Java interpreter. The Java interpreter is a module in the JVM that alternately decodes and executes one or more bytecodes. These bytecode instructions are designed to be easy to interpret on any machine and easy to be dynamically (on the fly) converted into native machine code.
[0042] Although the Java language is designed to be platform-independent and primarily executed in a secure environment, programmers can extend Java applications by using a compiled native language on the host operating system using a C-style calling convention through the Java Native Interface (JNI). In this way, Java applications can have full access to the host operating system, including reading or writing to attached I / O devices, memory, etc. Because of this, Java programs can become platform-specific at the expense of completing tasks that are not normally allowed by the JVM.
[0043] When calling native languages through JNI in compiled Java code, there is overhead involved. For example, work must be done at runtime to prepare the call for making it. Generally speaking, the native library containing the native function must be loaded before or at the time of calling the native function. The native function must also be resolved in the runtime system, and the relevant JVM data structures must be updated to indicate the use of the native function.
[0044] The embodiments of the present application are used in the compilation of source code for hybrid programming. The source code for hybrid programming includes native language code and non-native language code. In addition to calling their own function methods, such as a native language method calling a native language function method or a non-native language function method calling a non-native language function method, mutual calls between native language function methods and non-native language function methods may also occur. In the existing compilation method, since the native language and the non-native language are compiled independently of each other, when the native language is compiled, the non-native language is invisible to it; and when the non-native language is compiled, the native language is invisible to it.
[0045] refer to Figure 1 , describes the compilation process of the source code of hybrid programming, taking the hybrid compilation of Java and C / C++ as an example. In the Java virtual machine (JVM), the Java program is compiled into Java bytecode that is independent of the machine and operating system. The C / C++ program is compiled into a binary executable program related to the target machine. During the compilation phase, the Java program and the C / C++ program are invisible to each other. During the execution phase, the Java bytecode is first interpreted and executed by the interpreter. When the number of times the same section of code is executed reaches a certain threshold, it is compiled into machine-related binary code on the fly, and then the compiled binary code is executed on the fly. Java functions call C / C++ functions through JNI, and C / C++ functions call Java code and access Java objects / Java class objects through the reflection mechanism.
[0046] Figure 2 FIG. 1 shows an exemplary structural diagram of the terminal device 100. Figure 2The terminal device 100 includes: an application processor 101, a microcontroller unit (MCU) 103, a memory 105, a modem 107, a radio frequency (RF) module 109, a wireless fidelity (Wi-Fi) module 111, a Bluetooth module 113, a sensor 114, a positioning module 150, an input / output (I / O) device 115 and other components. These components can communicate through one or more communication buses or signal lines. Those skilled in the art can understand that Figure 1 The hardware structure shown in the figure does not constitute a limitation on the mobile phone. The mobile phone 100 may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.
[0047] Combine the following Figure 2 The various components of the terminal device 100 are described in detail:
[0048] The application processor 101 is the control center of the terminal 100, and uses various interfaces and buses to connect various components of the terminal device 100. In some embodiments, the processor 101 may include one or more processing units.
[0049] The memory 105 stores computer programs such as Figure 2 The operating system 161 and application 163 shown. The application processor 101 is configured to execute the computer program in the memory 105, so as to implement the functions defined by the computer program, for example, the application processor 101 executes the operating system 161 to implement various functions of the operating system on the terminal device 100. The memory 105 also stores other data besides the computer program, such as data generated during the operation of the operating system 161 and the application 163. The memory 105 is a non-volatile storage medium, generally including internal memory and external memory. The internal memory includes but is not limited to random access memory (Random Access Memory, RAM), read-only memory (Read-Only Memory, ROM), or cache, etc. The external memory includes but is not limited to flash memory, hard disk, optical disk, universal serial bus (universal serial bus, USB) disk, etc. The computer program is usually stored in the external memory, and the processor loads the program from the external memory to the internal memory before executing the computer program.
[0050] The memory 105 may be independent and connected to the application processor 101 via a bus; the memory 105 may also be integrated with the application processor 101 into a chip subsystem.
[0051] MCU 103 is a coprocessor for acquiring and processing data from sensor 114. The processing power and power consumption of MCU 103 are less than those of application processor 101, but it has the feature of "always on". It can continuously collect and process sensor data when application processor 101 is in sleep mode, and ensure the normal operation of the sensor with extremely low power consumption. In one embodiment, MCU 103 can be a sensor hub chip. Sensor 114 can include a light sensor and a motion sensor. Specifically, the light sensor can include an ambient light sensor and a proximity sensor, wherein the ambient light sensor can adjust the brightness of display 151 according to the brightness of the ambient light, and the proximity sensor can turn off the power of the display screen when the terminal device 100 moves to the ear. As a kind of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), and can detect the magnitude and direction of gravity when stationary; the sensor 114 can also include other sensors such as gyroscope, barometer, hygrometer, thermometer, infrared sensor, etc., which will not be repeated here. The MCU 103 and the sensor 114 may be integrated into the same chip, or may be separate components connected via a bus.
[0052] Modem 107 and RF module 109 constitute the communication subsystem of terminal device 100, which is used to implement the main functions of wireless communication standard protocols such as 3GPP and ETSI. Among them, Modem 107 is used for encoding and decoding, modulation and demodulation of signals, equalization, etc. RF module 109 is used for receiving and sending wireless signals, and RF module 109 includes but is not limited to antenna, at least one amplifier, coupler, duplexer, etc. RF module 109 cooperates with Modem 107 to realize wireless communication function. Modem 107 can be used as a separate chip, or it can be formed into a system-level chip or integrated circuit with other chips or circuits. These chips or integrated circuits can be applied to all terminal devices that realize wireless communication functions, including: mobile phones, computers, notebooks, tablets, routers, wearable devices, cars, home appliances, etc.
[0053] The terminal device 100 can also use a Wi-Fi module 111, a Bluetooth module 113, etc. for wireless communication. The Wi-Fi module 111 is used to provide the terminal device 100 with network access that complies with Wi-Fi related standard protocols. The terminal device 100 can access a Wi-Fi access point through the Wi-Fi module 111 to access the Internet. In some other embodiments, the Wi-Fi module 111 can also be used as a Wi-Fi wireless access point to provide Wi-Fi network access for other terminal devices. The Bluetooth module 113 is used to implement short-range communication between the terminal device 100 and other terminal devices (such as mobile phones, smart watches, etc.). The Wi-Fi module 111 in the embodiment of the present application can be an integrated circuit or a Wi-Fi chip, etc., and the Bluetooth module 113 can be an integrated circuit or a Bluetooth chip, etc.
[0054] The positioning module 150 is used to determine the geographical location of the terminal device 100. It is understandable that the positioning module 150 can specifically be a receiver of a positioning system such as a global positioning system (GPS) or a Beidou satellite navigation system or a Russian GLONASS.
[0055] The Wi-Fi module 111, the Bluetooth module 113 and the positioning module 150 can be separate chips or integrated circuits, or they can be integrated together. For example, in one embodiment, the Wi-Fi module 111, the Bluetooth module 113 and the positioning module 150 can be integrated into the same chip. In another embodiment, the Wi-Fi module 111, the Bluetooth module 113, the positioning module 150 and the MCU 103 can also be integrated into the same chip.
[0056] The input / output device 115 includes, but is not limited to, a display 151 , a touch screen 153 , and an audio circuit 155 , etc.
[0057] The touch screen 153 can collect touch events of the user of the terminal device 100 on or near it (for example, the user uses a finger, a stylus or any other suitable object on the touch screen 153 or near the touch screen 153), and send the collected touch events to other devices (for example, the application processor 101). The user's operation near the touch screen 153 can be called floating touch; through floating touch, the user can select, move or drag a target (such as an icon, etc.) without directly touching the touch screen 153. In addition, the touch screen 153 can be implemented by various types such as resistive, capacitive, infrared and surface acoustic wave.
[0058] The display (also called a display screen) 151 is used to display information input by the user or information presented to the user. The display may be configured in the form of a liquid crystal display, an organic light emitting diode, etc. The touch screen 153 may be overlaid on the display 151. When the touch screen 153 detects a touch event, it is transmitted to the application processor 101 to determine the type of the touch event. Then, the application processor 101 may provide a corresponding visual output on the display 151 according to the type of the touch event. Although in Figure 2 In the embodiment, the touch screen 153 and the display 151 are two independent components to realize the input and output functions of the terminal device 100, but in some embodiments, the touch screen 153 and the display 151 can be integrated to realize the input and output functions of the mobile phone 100. In addition, the touch screen 153 and the display 151 can be configured in the form of a full panel on the front of the terminal device 100 to realize a frameless structure.
[0059] The audio circuit 1155, the speaker 116, and the microphone 117 can provide an audio interface between the user and the terminal device 100. The audio circuit 109 can transmit the electrical signal converted from the received audio data to the speaker 113, which is converted into a sound signal for output; on the other hand, the microphone 114 converts the collected sound signal into an electrical signal, which is received by the audio circuit 109 and converted into audio data, and then the audio data is sent to, for example, another terminal device through the modem 107 and the radio frequency module 109, or the audio data is output to the memory 105 for further processing.
[0060] In addition, the terminal device 100 may also have a fingerprint recognition function. For example, a fingerprint acquisition device may be configured on the back of the terminal device 100 (e.g., below the rear camera), or a fingerprint acquisition device may be configured on the front of the terminal device 100 (e.g., below the touch screen 153). For another example, a fingerprint acquisition device may be configured in the touch screen 153 to implement the fingerprint recognition function, that is, the fingerprint acquisition device may be integrated with the touch screen 153 to implement the fingerprint recognition function of the terminal device 100. In this case, the fingerprint acquisition device is configured in the touch screen 153, may be a part of the touch screen 153, or may be configured in the touch screen 153 in other ways. The main component of the fingerprint acquisition device in the embodiment of the present application is a fingerprint sensor, which may use any type of sensing technology, including but not limited to optical, capacitive, piezoelectric or ultrasonic sensing technology.
[0061] Furthermore, the operating system 161 installed in the terminal device 100 may be Or other operating systems, the embodiments of the present application do not impose any limitations on this.
[0062] To carry Taking the terminal device 100 with an operating system as an example, the terminal device 100 can be logically divided into a hardware layer, an operating system 161, and an application layer. The hardware layer includes hardware resources such as the hardware processor 101, the microcontroller unit 105, the Modem 107, the Wi-Fi module 111, the sensor 114, the positioning module 150, etc. as described above. The application layer 31 includes one or more application programs, such as the application 163, which can be any type of application program such as a social application, an e-commerce application, a browser, etc. The operating system 161, as a software middleware between the hardware layer and the application layer, is a computer program that manages and controls hardware and software resources.
[0063] In one embodiment, the operating system 161 includes a kernel, a hardware abstraction layer (HAL) 25, libraries and runtime, and a framework. The kernel is used to provide underlying system components and services, such as power management, memory management, thread management, hardware drivers, etc.; hardware drivers include Wi-Fi drivers, sensor drivers, positioning module drivers, etc. The hardware abstraction layer is an encapsulation of the kernel driver, providing an interface to the framework 29 and shielding the implementation details of the lower layer. The hardware abstraction layer runs in the user space, while the kernel driver runs in the kernel space.
[0064] The library and runtime are also called runtime libraries, which provide the required library files and execution environment for the executable program at runtime. In one embodiment, the library and runtime include Android Runtime (ART), library, and scene package runtime. ART is a virtual machine or virtual machine instance that can convert the bytecode of an application into machine code. The library is a program library that provides support for the executable program at runtime, including a browser engine (such as webkit), a script execution engine (such as JavaScript engine), a graphics processing engine, etc. The scene package runtime is the operating environment of the scene package, mainly including a page execution environment (page context) and a script execution environment (script context), wherein the page execution environment parses page codes in formats such as html and css by calling the corresponding library, and the script execution environment parses and executes codes or executable files implemented in scripting languages such as JavaScript by calling the corresponding function library.
[0065] The framework is used to provide various basic common components and services for the application programs in the application layer 31, such as window management, location management, etc. In one embodiment, the framework includes a geo-fence service, a policy service, a notification manager, etc.
[0066] The functions of the various components of the operating system 161 described above may be implemented by the application processor 101 executing a program stored in the memory 105 .
[0067] Those skilled in the art will appreciate that the terminal 100 may include Figure 2 Fewer or more components than shown, Figure 2 The terminal device shown only includes components that are more relevant to the multiple implementation methods disclosed in the embodiments of the present application.
[0068] Reference Figure 3 , the block diagram shows the relationship of each software component running in the computer system that can implement the present application. The Java-based system includes a platform-specific operating system 302, which provides hardware and system support for the software executed on a specific hardware platform. JVM 304 is a software application that can be executed together with the operating system. JVM 304 provides a Java runtime environment, which has the ability to execute Java applications 306, and the Java applications or applets are programs, small services, or software components written in the Java programming language. The computer system in which JVM 304 runs can be similar to the data processing system 200 or computer 100 described above. However, JVM 304 can be implemented in dedicated hardware on a so-called Java chip with an embedded picoJava kernel, Java-on-silicon, or a Java processor.
[0069] At the center of the Java runtime environment is the JVM, which supports all aspects of the Java environment, including its architecture, security features, mobility across networks, and platform independence.
[0070] The JVM is a virtual computer, i.e. a computer that is specified in the abstract. The specification defines certain features that each JVM must implement, and has a range of design choices that may depend on the platform on which the JVM is designed to execute. For example, all JVMs must execute Java bytecodes, and may use a range of techniques to execute the instructions represented by the bytecodes. The JVM may be implemented entirely in software or to some extent in hardware. This flexibility allows different JVMs to be designed for mainframe computers and PDAs.
[0071] JVM is the name of the virtual computer component that actually executes Java programs. Java programs are not run directly by the central processor, but by the JVM, which is itself a piece of software that runs on the processor. The JVM allows Java programs to be executed on different platforms, rather than just on the one platform for which the code is compiled. Java programs are compiled for the JVM. In this way, Java can support applications for many types of data processing systems, which may include various central processing units and operating system architectures. In order to enable Java applications to be executed on different types of data processing systems, the compiler typically generates an architecture-neutral file format. The compiled code can be executed on many processors as long as there is a Java runtime system. The Java compiler generates bytecode instructions that are not specific to a specific computer architecture. Bytecode is machine-independent code generated by the Java compiler and executed by the Java interpreter. The Java interpreter is a part of the JVM that alternately decodes and interprets one or more bytecodes. These bytecode instructions are designed to be easy to execute on any computer and easy to be dynamically (on the fly) converted into native machine code. The bytecode can be converted into native code by a just-in-time (JIT) compiler.
[0072] The JVM loads the class files and executes the bytecodes in them. Class files are loaded by the class loader in the JVM. The class loader loads the class files from the application and loads the class files from the Java application programming interface (API) required by the application. The execution engine that executes the bytecodes may vary from platform to platform and implementation to implementation.
[0073] Figure 4 This is a flow chart of a method in an embodiment of the present application. This method is applied in the compilation stage of program source code, and is specifically as follows:
[0074] S401, obtaining a program source code, where the program source code includes a local language code and a non-local language code.
[0075] The program source code obtained is a mixed programming program source code, which includes local language code and non-local language code. The local language code includes local language methods, and the non-local language includes non-local language methods. There are mutual calls between local language methods and non-local language methods.
[0076] S402, generating an intermediate language code, converting the native language methods and non-native language methods in the source code into intermediate language methods.
[0077] During the compilation process, the native language code and non-native language code in the program source code need to be converted into a common intermediate language representation, which is an intermediate code. To convert the native language code and non-native language code into a common intermediate language, it is necessary to first convert the methods in the source code into intermediate language methods. When converted into intermediate language representation, the function bodies of the intermediate language methods converted from native language and non-native language methods are the same, and the difference lies in the scope of the function definition. For example, the intermediate language method corresponding to the native language method defines a global function, while the intermediate language method corresponding to the non-native language method defines a class method in a class. Therefore, in the intermediate language method, for the method corresponding to the non-native language, the class information of the non-native language is retained.
[0078] Taking Java and C / C++ as an example, the native language C and the sub-native language Java each implement a method function foo in the code. During the compilation process, the Java language and C / C++ language programs are first converted into a unified intermediate language representation. If the C / C++ language defines a global foo function, and the Java language defines a class method foo of the class internTest. After conversion into the intermediate language identifier, the main difference between the intermediate language method corresponding to the Java language class method foo and the global function foo defined in the C / C++ language is that the definition of the class method retains the class information, and the first parameter of the function is the this pointer. If a class method foo with a class name of internTest is defined in the C++ language, and a class method foo of the class internTest is defined in the Java language, the intermediate language method function body converted by the two is the same, and the class information is also the same.
[0079] In some implementations, the intermediate language method will have a function attribute identifier, which is used to indicate whether the intermediate language method is converted from the native language or from the non-native language. This identifier can be used to quickly unload the stack when an exception occurs during the running process.
[0080] In some implementations, the class inheritance relationship (CHA) can also be constructed in the intermediate language. For example, a virtual function table is generated in the intermediate language during the compilation phase according to the inheritance relationship. Figure 5 For example, the definitions of the four classes are as follows:
[0081] class A {fooA();}
[0082] class B extend A { fooB();}
[0083] class C extend B { fooA();}
[0084] class D extend B { fooD();}
[0085] The inheritance relationship of the four classes is as follows Figure 5 As shown, class B inherits class A, class C inherits class B, and class D also inherits class B. Figure 6 The virtual function tables (VMT) of four classes are given. At the virtual function call point, the index of the function in the virtual function table is also determined at compile time. During the execution of the intermediate language at run time, the process of virtual function call is as follows: determine which class the object is an instance of, for example, determine which class a pointer is an instance of; use the function index to search in the virtual function table of the corresponding class to determine the actual function called; return the actual function pointer called.
[0086] In some implementations, an interface function table of the class can also be added to the intermediate language. The interface function table includes a hash table and a conflict resolution table. When the program executes an interface function of the class at runtime, the hash value of the function signature is used to search in the hash table. If the function is found, the function address is returned; otherwise, the function signature is used to search in the conflict resolution table and the function address is returned.
[0087] For example, when compiling a Java program, all interfaces implemented by a class are collected. Due to multiple inheritance, interface functions cannot be sorted like functions in class inheritance to generate a function table. For all interface functions implemented by a class, a hash table is generated according to the function signature during compilation, and the corresponding function pointers are stored in the hash table. When a conflict occurs, a conflict resolution table is constructed to save the function signature and the corresponding function pointer. For example, the following are the three interfaces implemented by A, from which we can know that class A needs to implement three interface functions, fooB, fooC and fooD:
[0088] interface B {fooB();}
[0089] interface C {fooC();}
[0090] interface D {fooD();}
[0091] class A implements B,C,D{}
[0092] Figure 7An example of the interface function hash table and conflict resolution table of class A is described. In the hash table, the function pointer corresponding to fooC is filled in the corresponding position according to the hash value of the function signature of fooC. Positions where there is no corresponding function or there are more than one corresponding function (conflict occurs) are filled with 0. When a conflict occurs, for example, the hash value of fooB's signature is the same as the hash value of fooD's signature, the conflict resolution table saves the signatures of each function and the corresponding function addresses. Since the calculation of the interface function table and the function signature hash value are completed at compile time, a variable-length hash table can be used and multiple hash functions can be tried to reduce conflicts and reduce the size of the hash table, thereby reducing memory consumption and improving virtual call performance.
[0093] Combination Figure 7 During the execution of the intermediate language code, the following method flow describes how the interface function table is used.
[0094] S701, determine which class the object is an instance of;
[0095] S702, search in the hash table of the corresponding class according to the hash value of the function signature, and return the function pointer if found, otherwise search in the conflict elimination table using the function signature;
[0096] S703. Return the function pointer actually called.
[0097] In some implementations, data required for non-native language reflection is generated in the intermediate language code, including class metadata information, class domain information, and class method information. For example, when the non-native language is Java, JNI interface functions such as GetMethodID and CallVoidMethod are converted into Intrinsics through class metadata information, class domain information, and class method information, and the semantics of these Intrinsics can be known to the compiler.
[0098] For example, Figure 8 In the example, box A shows a code example of C / C++ calling a Java function. Boxes B, C, and D respectively show the data structures of the class metadata information, class method information, and class field information generated in the intermediate language code during compilation. During the execution of the intermediate language code:
[0099] 1) The FindClass function searches for the ClassMetadata information of all classes and finds the ClassMetadata of the corresponding class by comparing the parameters and classname;
[0100] 2) The GetMethodID function finds the information of all methods of the class through methods in ClassMetadata, and then uses the second and third parameters (function name, function parameters and return value information) to find the corresponding method;
[0101] 3) Function NewObjectA calls the Java method corresponding to con, the method pointer is saved in addr in MethodMetadata, and a Java object is created;
[0102] 4) Call the class method corresponding to mid in the class;
[0103] 5) The function GetFieldID finds the information of all the fields of the class through the fields in ClassMetadata, and then uses the second and third parameters (field name, field type information) to find the corresponding field;
[0104] 6) The function SetObjectField assigns a value to the fid field of the object jobj. If the field is a non-static field, the realOffset in the field information gives the offset of the field in the jobj object; if the field is static, the absAddress in the field information gives the address of the static field.
[0105] S403: Generate a calling method in the intermediate language for calling each other between the method converted from the non-native language and the method converted from the native language.
[0106] By converting both native language and non-native language methods into intermediate language methods, the native language methods and non-native language methods that have a mutual calling relationship are mutually visible through the converted intermediate language methods during the compilation process. Therefore, based on the converted intermediate language methods, the native language methods and non-native language methods that originally had a mutual calling relationship can be analyzed and optimized, thereby generating optimized methods for mutual calling between native language methods and non-native language methods.
[0107] In some implementations, the calling method in the intermediate language is used to combine the method converted from the non-native language with the method converted from the native language at runtime to jointly complete the call between the method converted from the non-native language and the method converted from the native language.
[0108] In other implementations, when generating a calling method in an intermediate language, the method converted from the non-native language and the method converted from the native language can be integrated into the calling method in an inline manner, so that at runtime, the calling method can independently implement mutual calls between the method converted from the non-native language and the method converted from the native language.
[0109] The following is an example to illustrate how to generate a calling method in an intermediate language for calling a method converted from a non-native language and a method converted from a native language.
[0110] like Fig. 9 As shown, in Fig. 9 In the example, the Java class Callbacks declares a call to a C / C++ function nativeMethod. Box B describes the definition of the C / C++ function nativeMethod, which finally calls the class method callback of the Callbacks class by calling the JNI interface functions GetObjectClass, GetMethodID, and CallVoidMethod. For standard JNI, the function to be called can only be found through the parameter obj at runtime. In this example, since the methods in box A and box B are both converted into intermediate language representations, that is, for the compiler, the inheritance relationship of the Callbacks class and the definition of the function nativeMethod can be obtained at the same time. Therefore, the inheritance relationship of the Java-side Callbacks class can be passed to the C / C++ side through the compiler, and after the compiler knows the semantics of the JNI interface function, it can be analyzed to obtain that CallVoidMethod finally calls the class method callback of the Callbacks class. Therefore, a function such as the one in box C can be generated in the intermediate code. Compared with the nativeMethod function in box B, the function in box C deletes a parameter (JNI interface pointer) and the original JNI interface function call. The function in box C can be used for mutual calls between the native language method nativeMethod and the non-native language method callback.
[0111] In some implementations, program analysis and optimization may also be performed on the Java and C / C++ functions in Box A and Box C. First, the nativeMethod is inlined into the main function, and then the callback function is also inlined into the main function, and finally the function shown in Box D is obtained.
[0112] S404, generating an executable binary executable program according to the analyzed and optimized intermediate language, and completing the compilation process.
[0113] Through the embodiment of the present application, when compiling a mixed source code containing a native language and a non-native language, the native language and the non-native language are converted into an intermediate language, and a calling method is generated according to the method calling relationship between the native language and the non-native language, for mutual calling between methods in the intermediate language. Since the compiler can simultaneously obtain method information of the native language and the non-native language through the intermediate language, when generating a calling method between the native language and the non-native language, the calling method can be optimized according to the method information of the native language and the non-native language. Compared with the prior art, the embodiment of the present application reduces the overhead of mutual calling between native language and non-native language methods at runtime.
[0114] Based on this embodiment, several embodiments are used below to illustrate how to analyze and optimize the intermediate language method during the intermediate language generation process, thereby generating a method for mutual calling between the local language method and the non-native language method.
[0115] refer to Fig.10 , is an optimization process of an intermediate language provided in an embodiment of the present application. This embodiment is based on Figure 4 In the embodiment, after conversion into the intermediate code, a calling method is generated in the intermediate code for mutual calling between the method converted from the non-native language and the method converted from the native language.
[0116] S1001, determining whether an exception occurs in the local language method.
[0117] The compiler can determine whether an exception will be thrown when the native language method is called by the non-native language based on the native language method called by the non-native language after conversion in the intermediate language.
[0118] S1002, if an exception occurs, an exception handling function is added to the calling method used for the non-native language to call the native language method. For example, in some examples, a call to checkPendingException can be added to the calling function used for Java to call C / C++ to implement the exception handling function.
[0119] S1003, if no exception occurs, the calling method does not include an exception handling function.
[0120] Through this embodiment, when generating a calling method for a non-native language to call a native language, it is first determined whether the native language method will throw an exception when called by the non-native language, and then it is determined whether to add an exception handling function to the calling method based on the determination result. Compared with the prior art that when Java calls a native language method, it is necessary to call exception handling at runtime to check whether there is an unhandled exception object, this embodiment generates a calling function at the compilation stage, and only includes an exception handling function when the native language generates an exception, thereby reducing the exception handling overhead at runtime.
[0121] refer to Fig.11 , is another intermediate language optimization process provided by the embodiment of the invention. This embodiment is based on Figure 4 In the embodiment, after conversion into the intermediate code, a calling method is generated in the intermediate code for mutual calling between the method converted from the non-native language and the method converted from the native language.
[0122] S1101: Determine whether the native language accesses an object in a non-native language
[0123] The compiler can determine whether the native language method will access the object in the non-native language based on the native language method called by the non-native language after conversion in the intermediate language.
[0124] S1102: If the native language method accesses an object in a non-native language, then when generating an intermediate language code according to the source program code, an object reference table in the non-native language code is generated.
[0125] S1103: If the native language method does not access the object in the non-native language, then when the intermediate language code is generated according to the source program code, an object reference table in the non-native language code is not generated.
[0126] In order to prevent Java objects from being recycled when C / C++ functions operate Java objects, it is necessary to track all Java objects involved in the parameters. Usually these Java objects will be organized into an object reference table. In an embodiment of the present application, when generating intermediate code, the references to Java objects in the C / C++ program can be analyzed, a Java object reference table can be created on demand, and references that are no longer used can be released in a timely manner. Thus, the overhead caused by creating an object reference table can be reduced.
[0127] refer to Fig.12 , is another intermediate language optimization process provided by the embodiment of the invention. This embodiment is based on Figure 4 In the embodiment, when the non-native language is Java, after conversion into intermediate code, a calling method is generated in the intermediate code for mutual calling between the method converted from the non-native language and the method converted from the native language.
[0128] S1201. Determine whether the native language method accesses the JNI interface pointer in the Java code. If so, add the JNI interface pointer to the parameters of the calling method between the native language and the non-native language in the intermediate code; if not, do not add the JNI interface pointer to the parameters of the calling method.
[0129] S1202. Determine whether the method in the native language accesses a Java object or a Java class object in the Java code. If so, add the Java object or the Java class object to the parameters of the calling method between the native language and the non-native language in the intermediate code; if not, do not add the Java object or the Java class object to the parameters of the calling method.
[0130] In some implementations, the native language can be inlined into a calling method in the intermediate language or into a method corresponding to the non-native language.
[0131] In this embodiment, when the intermediate code is regenerated, it is determined whether to add the JNI interface pointer, Java object or Java class object to the calling method based on whether the native language method accesses the JNI interface pointer in the Java code or accesses the Java object or Java class object in the Java code. Compared with the prior art, the calling overhead caused by the JNI interface pointer, Java object or Java class object can be reduced.
[0132] The method of the embodiment of the present application is described in detail above, and the device of the embodiment of the present application is provided below.
[0133] See also Fig.13 , Fig.13 1300 is a logical structure diagram of a compilation system 1300 provided in an embodiment of the present application. The compilation system of this embodiment can be set on a compiler. The system may include multiple logic units, and each logic unit performs a corresponding function. The logic unit is divided according to the interaction of function and information. It can be understood that each logic unit can be implemented by software or hardware, can be implemented by different hardware respectively, or can be implemented by common hardware. In addition, the division of the logic unit can also be adjusted according to different specific implementation methods. The division method in this embodiment is only exemplary. In this embodiment, the detailed description of each unit is as follows.
[0134] The acquisition module 1301 is used to acquire program source code, where the program source code includes native language code and non-native language code.
[0135] For the specific functional implementation of the acquisition module, reference may be made to step S401 in the aforementioned embodiment.
[0136] The intermediate language generation module 1302 is used to generate intermediate language code and convert the native language methods and non-native language methods in the source code into intermediate language methods.
[0137] In some implementations, the intermediate language generation module 602 may include a function attribute identifier in the intermediate language method, which is used to indicate whether the intermediate language method is converted from a native language or a non-native language. This identifier can be used to quickly unstack when an exception occurs during operation.
[0138] In some implementations, the intermediate language generation module 602 adds an interface function table of the class in the intermediate language. The interface function table includes a hash table and a conflict resolution table. When the program executes an interface function of the class at runtime, the hash value of the function signature is used to search in the hash table. If the function is found, the function address is returned; otherwise, the function signature is used to search in the conflict resolution table and the function address is returned.
[0139] In some implementations, the intermediate language generation module 602 generates data required for non-native language reflection in the intermediate language code, including class metadata information, class domain information, and class method information. For example, when the non-native language is Java, JNI interface functions such as GetMethodID and CallVoidMethod are converted into Intrinsics through class metadata information, class domain information, and class method information, and the semantics of these Intrinsics can be known to the compiler.
[0140] The intermediate language generating module 1302 may refer to the description of step S402 in the above-mentioned embodiment.
[0141] The calling method generating module 1303 is used to generate a calling method in the intermediate language for mutual calling between the method converted from the non-native language and the method converted from the native language.
[0142] In some implementations, the calling method in the intermediate language is used to combine the method converted from the non-native language with the method converted from the native language at runtime to jointly complete the call between the method converted from the non-native language and the method converted from the native language.
[0143] In other implementations, when generating a calling method in an intermediate language, the method converted from the non-native language and the method converted from the native language can be integrated into the calling method in an inline manner, so that at runtime, the calling method can independently implement mutual calls between the method converted from the non-native language and the method converted from the native language.
[0144] The calling method generating module 1302 may refer to the description in step S403 in the above-mentioned embodiment.
[0145] The optimization module 1304 is used to optimize the generated intermediate language.
[0146] In some implementations, the optimization module 1304 is used to determine whether an exception will occur in the native language method. If an exception will occur, an exception handling function is added to the calling method used for the non-native language to call the native language method.
[0147] In some implementations, the optimization module 1304 is used to determine whether the native language accesses objects in the non-native language. If the native language method accesses objects in the non-native language, an object reference table in the non-native language code is generated when the intermediate language code is generated according to the source program code.
[0148] In some implementations, the optimization module 1304 is used to determine whether the native language method accesses the JNI interface pointer in the Java code. If so, the JNI interface pointer is added to the parameters of the calling method between the native language and the non-native language in the intermediate code.
[0149] In some implementations, the optimization module 1304 is used to determine whether the method in the native language accesses a Java object or a Java class object in the Java code. If so, the Java object or the Java class object is added to the parameters of the calling method between the native language and the non-native language in the intermediate code.
[0150] The optimization module 1304 can refer to the aforementioned Fig.10 , Fig.11 , Fig.12 The description in the corresponding method embodiment.
[0151] Compilation module 1305 is used to generate an executable binary executable program according to the analyzed and optimized intermediate language to complete the compilation process.
[0152] Provided by the embodiments of the present application, when compiling a mixed source code containing a native language and a non-native language, by converting the native language and the non-native language into an intermediate language, and generating a calling method based on the method calling relationship between the native language and the non-native language, the calling method is used for mutual calling between the methods in the intermediate language. Since the compiler can simultaneously obtain the method information of the native language and the non-native language through the intermediate language, when generating the calling method between the native language and the non-native language, the calling method can be optimized based on the method information of the native language and the non-native language. Relative to the prior art, the embodiments of the present application reduce the overhead of mutual calling between the native language and the non-native language methods at runtime.
[0153] With the development of technology, designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, a method flow can also be implemented by a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.
[0154] The modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. Figure 2 The corresponding terminal system 100 is used to implement the present invention. Figure 2In the embodiment, a processor 101 is connected to a memory 105 via a bus. The memory 105 is a computer-readable storage medium that can be used to store software programs, computer executable programs, and modules. Figure 4-12 Program instructions / modules corresponding to the methods in any of the illustrated embodiments. The processor 101 executes the software programs, instructions and modules stored in the memory 105 to perform various functional applications and data processing of the computer device, that is, to implement the above methods.
[0155] In other implementations, a typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a server, a laptop computer, etc. However, with the development of technology, the computing power and communication capabilities of hardware devices will continue to increase. Therefore, it is foreseeable that in future technical implementations, various hardware devices with computing power and communication capabilities will be used as hardware devices of the compilation system described above. For example, cellular phones, smart phones, personal digital assistants, media players, car computers, Internet of Things devices, navigation devices, game devices, tablet computers, etc.
[0156] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.
[0157] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.
[0158] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0159] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0160] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0161] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.
Claims
1. A compiling method, characterized in that: The method comprises: Obtaining source program code, the source program code including a first language code and a second language code, the first language code including a first method, the second language code including a second method, wherein the first language code is a local language, and the second language code is a non-local language; A third language code is generated according to the source program code, wherein the third language code includes a third method and a fourth method, wherein the third method is generated according to the first method, and the fourth method is generated according to the second method, and the third language code also includes a fifth method, wherein the fifth method is generated according to the first method and the second method or according to the third method and the fourth method, and the fifth method is used for the third method to call the fourth method through the fifth method or for the fourth method to call the third method through the fifth method; and the third language code also includes class domain information, class method information, and class inheritance relationship in the second language code.
2. The method according to claim 1, characterized in that: Generating the third language code according to the source program code specifically includes: Determining that the first method or the third method will be abnormal; A fifth method is generated for the fourth method to call the third method, wherein the fifth method includes an exception handling function.
3. The method according to claim 1, characterized in that: Generating the third language code according to the source program code further includes: Determining that the first method accesses an object in the second language code; When generating the third language code according to the source program code, an object reference table of the object in the second language code is generated.
4. The method according to claim 1, characterized in that: The second language code is a Java language code, and generating the third language code according to the source program code further includes: Determine that the first method accesses a Java Native Interface (JNI) pointer in the second language code; A JNI pointer is added to the parameters of the fifth method.
5. The method according to claim 1, characterized in that: The second language code is a Java language code, and generating the third language code according to the source program code further includes: Determining whether the first method accesses a Java object or a Java class object in the second language code; The Java object or the Java class object is added to the parameters of the fifth method.
6. The method according to claim 1, characterized in that: When generating the third language code according to the source program code, generating the fifth method includes: According to the inheritance relationship of the class and the method information of the class, determine the signature of the second method in the second language code, the signature is used to indicate the name of the second method in the second language code and the class to which the second method belongs, and generate the fifth method according to the signature.
7. The method according to claim 1, characterized in that: Generating the third language code according to the source program code further includes: A sixth method is generated according to the inheritance relationship of the class and the domain information of the class, and the sixth method is used to access the domain in the second language code.
8. The method according to any one of claims 1 to 7, characterized in that: The third method and the fourth method include an identifier, and the identifier is used to indicate that the third method is generated according to a local language or to indicate that the fourth method is generated according to a non-local language.
9. A compiling device, characterized in that: The device comprises: an acquisition module, configured to acquire source program code, the source program code including a first language code and a second language code, the first language code including a first method, the second language code including a second method, wherein the first language code is a local language, and the second language code is a non-local language; a generating module, configured to generate a third language code according to the source program code, wherein the third language code includes a third method and a fourth method, wherein the third method is generated according to the first method, and the fourth method is generated according to the second method; the third language code also includes a fifth method, wherein the fifth method is generated according to the first method and the second method or according to the third method and the fourth method, and the fifth method is used for the third method to call the fourth method through the fifth method or for the fourth method to call the third method through the fifth method; and the third language code also includes domain information of the class, method information of the class, and inheritance relationship of the class in the second language code.
10. The device according to claim 9, characterized in that: The generating module generates the third language code according to the source program code specifically including: Determining that the first method or the third method will be abnormal; A fifth method is generated for the fourth method to call the third method, wherein the fifth method includes an exception handling function.
11. The device according to claim 9, characterized in that: The generating module generates the third language code according to the source program code and further comprises: Determining that the first method accesses an object in the second language code; When generating the third language code according to the source program code, an object reference table of the object in the second language code is generated.
12. The device according to claim 9, characterized in that: The second language code is a Java language code, and when the generating module generates the third language code according to the source program code, the generating module further includes: Determine that the first method accesses a Java Native Interface (JNI) pointer in the second language code; A JNI pointer is added to the parameters of the fifth method.
13. The device according to claim 9, characterized in that: The second language code is a Java language code, and when the generating module generates the third language code according to the source program code, the generating module further includes: Determining whether the first method accesses a Java object or a Java class object in the second language code; The Java object or the Java class object is added to the parameters of the fifth method.
14. The device according to claim 9, characterized in that: When the generating module generates the third language code according to the source program code, generating the fifth method specifically includes: According to the inheritance relationship of the class and the method information of the class, determine the signature of the second method in the second language code, the signature is used to indicate the name of the second method in the second language code and the class to which the second method belongs, and generate the fifth method according to the signature.
15. The device according to claim 9, characterized in that: The generating module generates the third language code according to the source program code and is further used for: A sixth method is generated according to the inheritance relationship of the class and the domain information of the class, and the sixth method is used to access the domain in the second language code.
16. The device according to any one of claims 9 to 15, characterized in that: The third method and the fourth method include an identifier, and the identifier is used to indicate that the third method is generated according to a local language or to indicate that the fourth method is generated according to a non-local language.
17. A compiling device, characterized in that: The compiling device includes a processor and a memory. The memory stores executable program instructions; The processor reads the executable program instructions in the memory to execute the method according to any one of claims 1 to 8.
18. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on a computer, the computer-readable storage medium is used to execute the method according to any one of claims 1 to 8.
19. A computer program product, characterized in that Instructions are stored thereon, and when the instructions are executed on a computer, the computer is caused to execute the method according to any one of claims 1 to 8.
Citation Information
Patent Citations
System for translating diverse programming languages
US20080216060A1
Method And Apparatus For Portable Stub Generation
US20090172652A1