Dalvik virtual Machines Overview
Dalvik is a Java virtual machine designed by Google to be used on Android platforms. Dalvik virtual Machine is one of the core components of Android mobile device platform developed by Google and other manufacturers. It can support the operation of a Java application that has been converted to. Dex (that is, Dalvik executable) format, which is a compression format designed for Dalvik and is suitable for systems with limited memory and processor speed. Dalvik is optimized to allow instances of multiple virtual machines to run concurrently in limited memory, and each Dalvik application executes as a standalone Linux process. A standalone process can prevent all programs from shutting down when the virtual machine crashes.
Development
The birth of Dalvik has also led to concerns that the first large-scale split of the Java platform may already be in progress-someone has linked Davlik to Microsoft's JVM and Sun's lawsuit against Microsoft, waiting to see if anything like that happens to Google. Others point out that Google does not claim that Dalvik is a Java implementation, and Microsoft does. Sun also expressed concern about the possible faction splits and offered to work with Google to ensure compatibility between the Dalvik and the JVM--google explained that Dalvik was an attempt to resolve the current split on the Java ME platform, Also to provide a platform with less restrictive licenses. There are even doubts about whether this is a big battle between Sun and Google's two camps over the future of Java. Ian Skerret believes that
Dalvik's birth was a response to Sun's attempt to control and protect the source of revenue from Java me, as well as the belated response to the establishment of the OPENJDK Governance Council.
This has led Dalibor topic to wonder if Google is going to Redo Sun's path:
A very interesting question, of course, is why no one has the courage to ask Google about OpenJDK's question in turn.
Although Android is known as open source, it is still a proprietary product. Android has a compatibility guarantee that is signed and kept in a secret meeting room.
Android does not have any governance models, and there is no evidence that governance models will emerge in the future. Android does not have a specification, and its license prohibits the development of any alternative implementations, as this is not the right to use the license granted by Google in the SDK license. Android is completely under Google's control, and Google retains the right to obliterate these apps once competitive applications are financially damaging to Google's interests. From the beginning of the design, Android has been limited, only in the context of Google's financial interests allowed to open. Proprietary Java is not a good thing, old bottles of new wine. It's like we're witnessing the rebirth of JCP, people lined up to put the open-source community's "street credit" in a single,
On the basis of proprietary implementations lent to another closed vendor Monopoly group. Only this time the big head changed the name of Google, not sun. (But when people call open source, they all seem to forget that the development of this series of software itself requires a great deal of investment, so the interests of the former, this is actually understandable.)
Stefano Mazzocchi published an analysis that deeply explored the licensing issues surrounding Java me and Dalvik, and concluded that Dalvik's market position was good enough to impact the mobile phone market. Although Google has been careful to avoid some of the key points of the lawsuit, Mazzocchi believes Sun will still be drafting a lawsuit against the intellectual property case (IBM is also possible). He also points out that Google can make changes to Android very quickly due to operations outside JCP, and that it can avoid Sun's veto of any JCP change-so they can also add interfaces to components such as USB and Bluetooth, which are in the underlying Java is not available in the ME implementation.
Finally, by authorizing Dalvik's source code under the Apache license, mobile phone operators are more likely to adopt Dalvik, as operators can use and modify it without the expense of licensing.
In addition, Java is no longer the only language that people have chosen to develop on Dalvik-there have been successes in running Scala on Dalvik, and HECL has been successfully ported. Another attempt to run groovy has been made, but so far it has not been successful. Miguel de Icaza, the founder of the Mono project, also expressed interest in integrating mono into Dalvik after the Dalvik source was open,
And there has been speculation about how to integrate in a variety of ways, including CIL (Common intermediate Language, Common Intermediate language) to Dalvik compilers similar to the Java-to-Dalvik compiler provided with the Android SDK.
Brief introduction
( DX is a set of tools that convert Java. class to. dex format. A dex file usually has more than one. Class. Because Dex sometimes has to be optimized, it increases the file size by 1-4 times, ending with ODEX . )
Dalvik and standard Java virtual machines (JVM) are the primary differences
The Dalvik is based on a register, and the JVM is stack-based.
Register - based VMs are less time-consuming when they are executed, for programs that become larger after compilation. (Also of register-based VMs allow faster execution times at the expense of programs which is larger after compilation.)
The difference between Dalvik and the Java operating environment
1:dalvik mainly includes the completion of object lifecycle management, stack management, thread management, security and exception management, as well as garbage collection and other important functions.
2:dalvik is responsible for process isolation and thread management, and each Android application will have a standalone Dalvik virtual machine instance at the bottom, and its code can be executed under the virtual machine interpretation.
3: Unlike Java Virtual machine running Java bytecode, Dalvik virtual machine is running its proprietary file format Dex
The 4:dex file format reduces the overall file size and improves the class lookup speed of I/O operations.
The 5:odex is designed to further improve performance during operation and further optimize the Dex file.
6: All Android apps have threads that correspond to a Linux thread, so virtual machines can rely more on the operating system's thread scheduling and management mechanisms
7: There is a special virtual machine process zygote, which is an incubator of virtual machine instances. It will be generated when the system starts, it will complete the initialization of the virtual machine, library loading, prefabricated class library and initialization operations. If the system needs a new instance of the virtual machine, it will quickly replicate itself and provide the system with the fastest data. For some read-only system libraries, all virtual machine instances share a memory area with zygote.
8:dalvik was written by Dan Bornstein, whose ancestors had lived in a small fishing village named Dalvík, a village in Iceland Eyjafjörður
Architecture
Unlike other stack-structured Java virtual machines, Dalvik uses a register-based architecture.
The DX tool converts some, but not all, Java. class files into. dex format. Multiple classes are included in a. dex file. To save space, repeated strings and other constants in each class file are stored only once in the. Dex output. The Java bytecode is converted into an alternate instruction set used by the Dalvik virtual machine. An uncompressed. dex file is usually smaller than the compressed. jar document from the same. class file.
The Dalvik executable may be modified when it is installed on a mobile device. For further optimization, the virtual machine may adjust the end sequence of some data in the file, inline some functions and simple structure, and short out some unnecessary operations.
Starting with Android 2.2, Dalvik supports JIT (Just-in-time, instant-compile technology).
Optimized Dalvik has some different features than other standard virtual machines
• Takes up less space
• For simplified translation, the constant pool uses only 32-bit indexes
• Standard Java bytecode implements 8-bit stack instructions. Dalvik uses a 16-bit instruction set to directly act on local variables. Local variables typically come from a 4-bit "virtual register" area. This reduces the Dalvik instruction count and improves the translation speed.
When Android starts, the Dalvik VM monitors All Programs (APK) and creates a dependency tree, optimizes the code for each program and stores it in the Dalvik cache. Dalvik The cache file is generated the first time it is loaded to provide the next quick load, so the first time is slow.
The Dalvik interpreter uses a pre-calculated goto address, and each instruction accesses the memory on a 64-byte boundary. This saves a command after the time to look up the table. For enhanced functionality, the Dalvik also provides a fast translator (fast interpreter).
Performance
Stack-based machines and register-based machines who have the advantage has always been a vexed topic.
In general, stack-based machines must use instructions to load and manipulate data from the stack, so they require more instructions to achieve the same performance than register-based machines. But the instructions on the register-based machine must be encoded, so their instructions tend to be larger. This difference is mainly caused by the operation code scheduling of VM pairs, which are often more expensive than other factors, such as compiling in time.
However, in 2010, standard non-graphical performance tests on embedded devices at Oracle Corporation (owner of Java Technology) showed that Android 2.2 (the original version includes an instant compiler) is 2-3 times slower than the Java SE Embedded device (both based on Java SE 6).
Class Library
The Dalvik virtual machine does not support either Java SE or Java me libraries (e.g. Java classes, neither AWT nor swing support). Instead, it uses its own built-in class library (a subset of Apache Harmony Java).
Android Dalvik Virtual Machine overview