Java plays a leading role in Embedded Application Development

Embedded Java plays an important role in the next generation of mobile phones, smart cards, wireless devices, game devices, and many other embedded applications. The key lies in which implementation method to choose.

Java has received much attention since its launch, but in the view of embedded system designers, its performance is not satisfactory. Run Java Virtual Machine (JVM) to explain the Java bytecode. This method occupies too much space for most embedded applications and runs too slowly. However, sun's Java 2 Micro Edition (j2s) has changed this situation.

For embedded system designers, Java has many advantages. AsProgramming LanguageJava allows object-oriented programming without any serious problems in C ++. For example, Java allows class inheritance, but does not allow multiple parent classes. This eliminates the possibility of confusion. Similarly, java prevents the uncertainty that may occur when the C ++ operator is defined. The Java Runtime Environment also provides useful attributes. It checksCodeThen execute the command to ensure the applicationProgramIt does not interfere with each other, and the entire system does not crash. If the code tries to change the core behavior of the system, it cannot run. The memory management function provided by Java makes it unnecessary for programmers to allocate and release memory, avoiding Memory leakage. It can also automatically release idle memory by means of garbage collection. The runtime environment can even simplify program allocation by integrating core class libraries.

In addition, Java is widely supported in the industry, which means there are a lot of resources available, including small applications and experienced programmers, so that no repetitive work is required to write new applications each time.

However, in addition to these advantages, the problem that Java is used for embedded development is that most embedded applications face two constraints that Java does not handle well: there is not enough space and time.

Time and space constraints for Java Development

The reason for the time constraints is that embedded systems usually have to respond to external events in a short period of time. If the system does not handle the previous event before the next event occurs, the task cannot be completed.

Time constraints also mean certainty. Designers rely on software elements to complete their respective tasks within a known or limited period of time. tasks without time constraints (such as waiting cycles) can be paused when they execute time-critical tasks.

The Spatial Constraints of embedded development come from the need for cost and portability. Designers need to use as little memory as possible, so that the design is limited by the on-chip memory resources of the microcontroller. However, this helps reduce power consumption, which is an important factor for battery-powered portable systems.

It is difficult for Java to work normally under these time and space constraints. The Java software environment should work with the operating system, and use the Java Virtual Machine to convert the Java bytecode into the local language of the system processor. It also requires a large class library as part of the core system. These two factors greatly increase the demand for system memory.

The Java interpreter code is not faster than the compilation code. As a result, the system is more difficult to meet real-time constraints. A faster processor may be helpful, but power consumption often makes embedded systems unable to use a faster processor. Even if the system is fast enough, Java garbage collectionAlgorithmThere is no time limit and no interruption, so it is impossible to obtain certainty.

Java

For problems encountered by Java in embedded development, Java 9-9 can solve some of them. The method is to reduce the size of the class library and change the garbage collection algorithm. The following table lists two types of Java: Connection Device Configuration (CDC) and connection limited device configuration (cldc. These Java replace older embedded Java, while the old version is actually a non-standard version of Java for custom applications.

CDC is a fully functional Java, designed for devices with network connections, 32-bit processors, and 2 MB memory for the Java platform. This version of Java allows devices to download and run common small applications in a way similar to a desktop machine. PDAs, household appliances, and vehicle navigation systems are suitable for target applications.

Cldc is a lite version of Java that is more customized for runtime environments. Cldc does not allow the running of common small applications, but requires the Java program to comply with the constraints of the device. In this way, the advantages of Java "writing once and running everywhere" cannot be discussed, but it still retains other advantages of Java programming. Cldc and its k virtual machines require KB of memory and 16 MHz of 16-bit processors.

With these two configurations, Sun has developed standard Java configurations that comply with the design space constraints of many embedded systems.CommunityThe developed Real-Time Java specifications solve real-time and deterministic problems. Real-Time Java specification (rtsj) V1.0 provides standard extensions for the Java platform and modifies the garbage collection algorithm to ensure the certainty required by many embedded applications.

This leaves the original performance issues that have not been resolved. The solution comes from a series of methods in the industry to speed up Java execution, including using the optimized JVM, compiling the Java code cost machine code before execution, using the JIT programmer and using hardware acceleration, each method has its own advantages and disadvantages.

Compared with General JVM, the optimized JVM can increase the execution speed by 2 ~ 2.5 times. However, such optimization depends on the specific processor. Vendors that provide optimized JVM may also provide optimized class libraries and real-time operating systems, which can work closely with JVM to further improve software performance.

No matter whether it is optimized or not, you still need to explain the work to use JVM, which limits the execution speed of the program. This restriction can be avoided by compiling and executing the Java code. In this case, Java becomes another advanced language similar to C ++. The factors limiting the execution speed depend entirely on the code efficiency of the compiler. The problem is that, like other advanced languages, this compilation must be performed before the code is embedded into the program memory. As a result, the system lacks flexibility, you cannot download the upgraded Java code or new application.

The timely compiler strives to use "high-speed" to compile Java code so that it can be executed immediately and regain this flexibility. This brings high performance and flexibility, but also increases the startup time of a specific application, because compilation needs to be started first. Because it occupies at least KB of memory (plus the memory required by JVM and applications), the use of timely compilers also increases the demand for system memory.

Hardware acceleration Java

To speed up Java execution and avoid the disadvantages of compiling or software JVM, embedded developers can turn to the hardware accelerator. This type of device transfers some or all JVM tasks to dedicated hardware for processing, thus improving the performance by 5 ~ 10 times. However, the hardware accelerator does not take over all tasks, and the host CPU still processes extremely complex or rarely used bytecode.

Semiconductor vendors have adopted several methods to speed up Java execution through hardware and work on different tasks.

One is to use a hardware interpreter. This interpreter converts most of the involved Java code into the machine code, saving JVM trouble. For example, nazomi's jstar, insilicon's jvx, and arm's jazelle. In most cases, the interpreter owns silicon intellectual property, which actually expands the instruction set of the processor.

Another method is to use a coprocessor. The coprocessor not only interprets bytecode, but also executes the generated machine code to completely free the CPU. A coprocessor is actually a kind of processor that uses Java bytecode as the local machine language. Some coprocessors such as insilicon's jvxtreme are pure coprocessors, while some coprocessors such as Aurora's espresso and decaf can act as coprocessors or independent processors, in this way, Java code can be processed when another CPU processes transactions such as the user interface. Ajile aJ-100, DCT Lightfoot, and zucow.xpresso are co-processors. Like interpreters, these coprocessors are often used as the core for ASIC or FPGA implementation.

The third method is to use the hardware compiler to quickly compile Java bytecode. This device is different from the hardware interpreter. It not only converts software from one form to another, but also compilation, including optimization and re-arrangement of code execution order. Parthus's machstream belongs to this category.

With this series of software and hardware solutions to speed up Java code execution, the Java performance problem of the embedded system seems to be solved. Unfortunately, it is difficult to predict how much performance they will bring. The interaction between the accelerator and other system units increases the difficulty of prediction. The CPU architecture, number of available system memory, real-time operating system (RTOs), JVM, class library, and hardware acceleration may affect the final performance of the system, and even the application software may affect the performance. For example, system software and hardware configurations suitable for internet devices may run slowly in the set-top box, and are not suitable for mobile phones.

Unfortunately, embedded designers do not have many tools to help themselves test the performance of nontraditional configurations. The most useful tool is the spec jvm98 benchmark developed by the system performance testing company. However, spec jvm98 is not designed to meet the testing requirements of embedded systems, but is developed for networked and independent clients. The premise is that Java is fully implemented and a complete desktop system environment is available, few embedded systems have such rich resources.

The benchmark of Pendragon software company caffeinemark is quite popular in the embedded field. Like the dhrystone MIPS benchmark, caffeinemark is also a manual benchmark that tests only a few Java features, excluding floating point operations, garbage collection, and multithreading, these embedded developers may be very important. In addition, no standard configuration is available for Benchmark Testing. Therefore, it is difficult to interpret the benchmark test results of different vendors.

For embedded Java, the lack of testing tools may not exist for a long time. The EDN embedded microprocessor Benchmark Testing Association (eembc) has begun developing Java benchmark testing kits. The eembc Benchmark Testing is prepared to use a variety of system testing indicators, including garbage collection time and certainty, I/O performance, interrupt latency, memory usage, and system power consumption during the testing process. It also includes detailed software execution benchmark tests, including the class loading time, class method execution, the number of threads used, the time used by each thread, and the time used to call the thread. The association plans to conduct benchmarking in a wide range of application environments, including smart cards, mobile phones, handheld devices, internet devices, and set-top boxes.

Once these tools are ready, they can be compared based on the expected applications, which greatly facilitates developers to choose many embedded Java solutions and ensure that the final performance of the system can meet expectations. In this way, Java can play a leading role in future embedded system development.