Research and Implementation of Java Virtual Machine Applied to Digital TV Set Top Box

introduction
With the development of cable radio and television networks in the direction of digitization, networking and industrialization, digital TV set-top boxes using cable television networks as transmission platforms can not only allow users to watch digital TV programs on existing analog TV sets, but also broadcast and interactive multimedia. The requirements of application functions have also emerged, and interactive TV has become the development direction of digital TV. The Java language widely used by many programmers for the network can meet the requirements of some service applications of the set-top box. Therefore, the system architecture of the digital TV set-top box middleware including the Java virtual machine is proposed. The virtual machine is used to execute the Java application. And the middleware isolates the application from the underlying operating system and hardware details, so that the service application of the upper digital TV does not have to consider too much underlying details. This paper mainly introduces the transplantation of CDC in J2ME, which is mainly used in the field of digital TV. It also introduces the implementation process of native method.

Structure and working principle

How the Java Virtual Machine works

Figure 1 The working process of the Java virtual machine

The Java virtual machine is between the machine and the compiler and provides a common interface to the compiler on any platform. The Java source program is compiled into a bytecode after being compiled by the compiler. The bytecode is interpreted and executed by the virtual machine. The virtual machine sends each bytecode to be executed to the interpreter, and the interpreter translates it into a machine on a specific machine. Code, then run on a specific machine.

The main task of the Java virtual machine is to load the class file and execute the bytecode in it. The Java virtual machine includes a class loader that loads class files from programs and APIs. The bytecode is executed by the execution engine. The specific process is shown in Figure 1.

Java virtual machine structure

The class loader architecture is an aspect of the Java virtual machine playing an important role in security and network mobility. The class loader shown in the figure can contain subsystems of multiple class loaders, and Java applications can run. It determines the classes that need to be installed, and stores the classes loaded by different class loaders in different namespaces.

The execution engine is at the core of the Java virtual machine. Its behavior is determined by the instruction set. Its main function is to interpret the bytecode (that is, the class file that runs the compiled Java program). Different execution engine implementations may be very different. The execution engine of the virtual machine implemented by software is divided into a one-time interpretation bytecode, a just-in-time compiler and an adaptive optimizer. The virtual machine composed of the hardware chip executes the Java bytecode in a local method, and its execution engine is embedded. In the chip.

A Java virtual machine is equivalent to a stack computer. It does not use any physical registers when transferring information between instructions. Instead, it uses the frame of the stack to represent the state of the method, the operation object of the bytecode, the parameter space of the method, and the space of the local variables. Its "program counter" is a pseudo-register that is a pointer to the bytecode array of the currently executing instruction.

Java implementation

Java has two implementation methods: Java methods and native methods. Java methods are written in the Java language, compiled into bytecode, and stored in a class file. Local methods are written by other languages ​​(such as C, C++, or assembly language), compiled into processor-related machine code, stored in a dynamic link library, the format is proprietary to each platform, it is associated with the Java program and The connection method of the underlying host operating system. The Java method is platform-independent, but the native method is not. When a running Java program calls a native method, the virtual machine loads the dynamic library containing the local method and calls this method. Through native methods, Java programs can directly access the resources of the underlying operating system, making the program relevant to a specific platform. A native method interface, the Java Native Interface (JNI), enables local methods to be available on any Java platform of a particular host system. run.

CDC migration solution in J2ME

The Java virtual machine we chose to port is the J2ME provided by Sun for CDC configuration in the digital TV field. The virtual machine is a software implementation for Linux (a virtual machine written in C language, also called C Virtual Machine. Referred to as CVM). The Java Virtual Machine Specification does not force the Java Virtual Machine to support any particular native method interface, but Sun provides a Java Native Interface for use in porting. The Java program interacts with the host by calling a local method.

Java virtual machine

Figure 2 Location of the Java virtual machine

The virtual machine is on the embedded operating system OS20, so the operations related to the underlying operating system in the Java virtual machine provided by Sun should be replaced with the kernel functions of OS20. Therefore, porting the CDC provided by Sun to OS20 requires some work, such as: modification of data bits of basic data types in C language, creation of threads (OS20 is a task), synchronization between threads, mutual exclusion Regarding the implementation of dynamic connections, the implementation of local methods, etc., this section mainly introduces the implementation process of local methods.

Local method

When the interpreter processes the bytecode, the semantics of the actions associated with the given bytecode, and the associated actions of executing the bytecode are mostly to get its operands from the stack and send the result back to the stack. The bytecode is typically parameterized, which follows the bytecode itself in the bytecode stream.

During the virtual machine's interpretation of the bytecode, the execution engine will occasionally encounter an instruction requesting a local method call, and the virtual machine is responsible for invoking the call of this local method. The native method is a programmable extension of the Java virtual machine instruction set. Running this native method is the execution of this instruction by the Java virtual machine.

Local method function call

In order to increase the performance of the virtual machine and speed up its speed, the native method function called by the interpreter when processing some bytecodes is implemented by assembly to convert the Java stack to the C stack, and then implement the function call on the C stack. Under Linux is a separate assembly language program invokeNative_i386. S implements the function CVMjniInvokeNative () , we implement the function by embedding the assembly form in C.

There are 7 formal parameters of the function. The main function of the function is to obtain the parameters of the local method by directly or arithmetically, and then push the local method parameters into the local stack, and implement the local C function call through assembly. The seven data passed by the argument include the JN I environment pointer (env), the native method's function pointer, the Java stack pointer (args), the local method descriptor (terse sig), and the total number of parameters of the Java stack ( Args size) indicates the class object of a static or non-static method and a return value used to store the return value, where env is passed as the argument to the first local method, and the native code is also Passed to the local method to implement the correct invocation of the local method.

CDC transplantation in J2ME

Since Linux has multiple general-purpose registers, registers such as esp, ebp, and esi are fully utilized in the code that implements this function, but the operand registers provided by OS20 have only three general-purpose registers Areg, Breg, Creg, and one working pointer. Register Wptr (equivalent to the stack pointer), in the implementation process, we use a local variable in the C function instead of the Linux general-purpose register, manually adjust the working stack pointer to achieve the local method call, the specific implementation process is shown in Figure 3. Show.

When entering the assembly function, the work area pointer is Wptr, the values ​​of the actual parameter, status register and instruction pointer register are all automatically pushed onto the stack, and then the local variable we defined instead of the Linux register is automatically pushed onto the stack. At this time, Wptr is automatically moved to Wptr', using OS20 assembly instructions, manually pass the parameters passed by the actual parameters to calculate the number of local method parameters, and then push the parameters required by the local method in turn, and then manually adjust the work area pointer to implement the local method. Successfully called. Here we first put the local method function pointer and a flag bit flag (0x10101010) onto the stack for two reasons:

1 When we manually adjust the working pointer Wptr' to Wptr", the working stack has been entered into the C function of the local method to be called by the previous nested assembly function, so the local variable of the previous function is invalid at this time. That is to say, if you use the local function pointer passed by the previous argument to call the local function, it will not succeed, so you should manually save the function pointer first.

The reason for setting 2flag is that the number of parameters of the local method is not fixed, and the assembly call function provided by OS20 only pops up the contents of the four units pointed to by Wptr when returning to the function entry point, so the extra parameters The pop operation must also be done manually by adjusting Wptr. By looking up the Wptr to find the flag flag, then adjusting Wp tr to Wtpr+2 to return to the assembly function correctly. When the parameters of the local method are completely manually pushed, you can manually Adjust the work area pointer Wptr to enter the called local function, the first thing after the function returns is the return value of the function saved in the register to the return value, restore the work area pointer Wptr, and the return value type of the local method as The return value of the function embedded in the assembly, at this point complete the conversion from the Java stack to the C stack, and successfully call the local method.

Figure 3 Java stack to local stack conversion


in conclusion

Through the modification and writing of the CDC code downloaded by Sun, some reductions were made to the loaded classes in the CDC, and the threaded interpreter was changed to a one-threaded interpreter simplified program that interprets bytecodes at one time, successfully A virtual machine is generated that can run a simple Java program on the set top box.



:
0 times
Window._bd_share_config = { "common": { "bdSnsKey": {}, "bdText": "", "bdMini": "2", "bdMiniList": false, "bdPic": "", "bdStyle": " 0", "bdSize": "24" }, "share": {}, "image": { "viewList": ["qzone", "tsina", "tqq", "renren", "weixin"], "viewText": "Share to:", "viewSize": "16" }, "selectShare": { "bdContainerClass": null, "bdSelectMiniList": ["qzone", "tsina", "tqq", "renren" , "weixin"] } }; with (document) 0[(getElementsByTagName('head')[0] || body).appendChild(createElement('script')).src = 'http://bdimg.share. Baidu.com/static/api/js/share.js?v=89860593.js?cdnversion=' + ~(-new Date() / 36e5)];

R134A compressor

Embraco Refrigerator Compressor,R134A Compressor,Commercial Refrigeration Compressor

Maidi Heating And Refrigerating Equipment Co., Ltd. , http://www.lydccompressor.com

Posted on