A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
Dalvik virtual machines exist in the Android system, the JVM is a Java virtual machine, both are virtual machines, what is the difference between them? This article compares the two to tell the difference between them.
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. (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. ）
Jvm:java Virtual mechinal (JavaVirtual Machines). JVM isJREpart of it is a fictional computer that is implemented by simulating various computer functions on a real computer. JVMhas its own perfect hardware architecture, such as processor, stack, register, etc., also has the corresponding instruction system. JVMThe main task is to interpret your own instruction set (that is, bytecode) and map it to a localCPUthe instruction set orOSsystem call. The Java language is run across platforms, in factdifferent operating systems, using a differentJVMmapping rules to be independent of the operating system, completing cross-platform. The JVM does not care about the Upper Java source files, it only focuses on the class file generated by the source file . the composition of the class file includesJVMinstruction set, symbol table, and some subsidy information.
(1)DalvikVirtual Machinesthe first difference from the JVM is DalvikVirtual Machinesis a register-based architecture (Reg based), and the JVM is a stack-based architecture (stack based). Reg basedVirtual Machinesthe benefit is that better pre-optimization (Ahead-of-time optimization) can be achieved. In addition, REG based VMS execute faster, but at the cost of a larger code length, typically 1-4 times. Dalvik has been optimized to allows instances of multiple virtual machines to run concurrently in limited memory, and each Dalvik application executes as a standalone Linux process.
(2) Another difference is that Dalvik can allow multiple instance to run, which means that each Android app runs independently of a VM. The benefit of this is that an app crash only affects its own virtual machine and does not affect the other. Dalvik's design is that every Dalvik virtual machine is a process under Linux. Then this requires an efficient IPC. In addition, each VM has the benefit of running independently and can dynamically active/deactive its own VMS without affecting other VMs. a process (all Android app threads are corresponding to one Linux thread, all running in their own sandbox, and different apps running in different processes.) Each Android Dalvik application is given a standalone Linux PID (app_*))
(3)the Java Virtual machine is running Java bytecode. (The Java class is compiled into one or more bytecode. class files, packaged into a. jar file,java virtual machine gets the appropriate bytecode from the appropriate. class file and the. jar file. dalvik is running the custom. Dex bytecode format. (After the Java class is compiled into a. class file, it is passed a DX tool convert all. class files to a. dex file
(4) Java VMS Each class has a constant pool, and the DVM has only one constant pool. The JVM is. Java text is compiled into a. Class bytecode file, and the class loader loads all the required classes into memory when executing Java programs. the Davik virtual machine compiles the. java file into a. class file, and then converts the. class file to a. dex file, Dalvik to execute the. dex file.
In fact, a. dex file is a combination of constants, methods, and so on in multiple class files.managed by a constant pool in the Dex file, see
============================= Split Line ===========================
Let me briefly summarize in my knowledge the impact of the architectural differences between DVM and JVM
the JVM's core purpose is to build a truly cross-OS platform, a program run environment (VM) across instruction sets. The purpose of the DVM is to provide the native resources and environment of the Android OS to the application development in a unified interface. Strictly speaking, DVM is not a real VM, it is just the environment that provides the VM at the time of development, and does not provide a real VM container at runtime. This is why the JVM must be designed to be stack-based.
JVM: All of the jar programs, the runtime environment is fully provided by the JVM, including the runtime, the scheduling of various resources, and the JVM's architecture, which is designed to run multiple Java programs within a JVM, the JVM is like a real "machine", can run multiple programs. If you look at some enterprise-class JVMs (such as Tom Cat,was), from the process management of the OS, you can see only one JVM process (of course, you could also have multiple JVMs, but the JVM architecture is the Os-jvm-app 3-tier runtime mode). You can't see the programs running inside the JVM, and in a JVM, you can run multiple Java apps. Simply put, the JVM completely masks the connection between the application and the OS, and instead the JVM acts as the middle tier, which is a true cross-platform runtime VM must do. As long as it is the same JDK,JVM for all programs running in it, provides a fully consistent running environment regardless of what kind of underlying OS and hardware conditions you are. So that's what I mentioned in one of the other answers, the JVM is characterized by the intersection of the underlying OS and hardware environment to ensure this consistency. The interaction of all applications and underlying resources must be implemented by relying on the JVM's delivery and transformation. The JVM really implements all of the features of an OS that are managed by the application runtime. From the development environment perspective and the runtime perspective, are exactly the same true VMS
DVM: While the DVM is characterized by the use of zygote,zygote there are several very interesting features.
The first is that the zygote uses preload, which determines the needs of the installed apk and the interdependence tree, as well as the characteristics of the OS and the hardware environment. Pre-load every time you start (now you understand why Android apps can easily find out why it's calling key local resources in app management?). This means that the more apps you install, the slower the load on the zygote, and the slower your phone will generally start. In addition, in different hardware environments (for example, there is no GPS chip) Zygote initialization of the instance is different. In other words, zygote does not provide a unified operating environment, with better elasticity, this mechanism means that the DVM can take the underlying resources of the collection to provide upper-level application use, the difference is only in the program installation or startup process, the DVM can prompt the program needs resources, The local environment may not be satisfied and will not run. DVM's zygote is not a runtime container, it provides only a process for sharing, all applications run, are independent, OS-level processes, directly affected by the OS level of resource control and scheduling, but they share zygote said preloaded classes. That's why I say that a DVM is like adding a condom to each application at the bottom, rather than providing a real runtime VM. In other words, the DVM says in the development environment that the provided VM platform and the runtime environment are likely to be inconsistent. The VM platform provided in the development environment is a collection of possible environments for a variety of runtimes.
from this point of view, in general, we think that the JVM of the Java program crashes, leading to the JVM crash, without causing the OS to crash, but the crash of the APK can directly lead to the OS crashes, Android phone because the application crashes, everyone should be very common. But people generally do not see the Java program caused the crash it? Because the runtime is separated by a JVM. (Of course, there are still some small doorway can use Java program to crash the OS, because this, I and some Java Danale bet to win dinner, hehe, but this is other topics, not here to unfold)
In addition, in the JVM mechanism, different programs, after packaging, they are at the running level of the real independent program (refers to the program to apply their relationship with each other, rather than the relationship with the JVM), even if they use the same class in the package, the runtime is loaded separately, run alone (and loaded multiple times).
DVM This preload-sharing mechanism enables different applications to share the same classes at run time, in general, with higher efficiency in terms of system resource consumption.
Finally, add that byte code does not mean to interpret execution, but also to load compile, install compile, pre-compile, and so on.
The difference between an Android virtual machine and a Java virtual machine
Start building with 50+ products and up to 12 months usage for Elastic Compute Service