Dalvik is a discontinuedprocess virtual machine (VM) in theAndroid operating system that executes applications written for Android.[1] (Dalvik bytecode format is still used as a distribution format, but no longer at runtime in newer Android versions.) Dalvik was an integral part of the Android software stack in the (now unsupported)Android versions4.4 "KitKat" and earlier, which were commonly used on mobile devices such asmobile phones andtablet computers, and more in some devices such assmart TVs andwearables. Dalvik isopen-source software, originally written by Dan Bornstein, who named it after the fishing village ofDalvík inEyjafjörður,Iceland.[2][3]
Programs for Android are commonly written inJava and compiled tobytecode for theJava Virtual Machine, which is then translated to Dalvik bytecode and stored in.dex (Dalvik EXecutable) and.odex (Optimized Dalvik EXecutable) files; related termsodex andde-odex are associated with respective bytecode conversions. The compact Dalvik Executable format is designed for systems that are constrained in terms ofmemory andprocessor speed.
The successor of Dalvik isAndroid Runtime (ART), which uses the same bytecode and .dex files (but not .odex files), with the succession aiming at performance improvements. The new runtime environment was included for the first time in Android 4.4 "KitKat" as atechnology preview,[4][5] and replaced Dalvik entirely in later versions;Android 5.0 "Lollipop" is the first version in which ART is the only included runtime.
Dalvik, named aftera town in Iceland by its creator Dan Bornstein,[6] was designed for embedded devices with very low RAM and CPU[7] to run Java code, and eventually supportC++ for "heavy-duty apps" andJavaScript for "light-weight widget-like apps" as first-class languages with Java catering to the rest.Android Native Development Kit which eventually paved way for C++ support has existed since Dalvik's first public release. According to Bornstein,Memory-mapping executables and libraries across multiple process and building a faster interpreter with register-based semantics drove much of the early design of the byte-aligned instruction set and the Virtual Machine. Experience working withJ2ME onSidekick atDanger, Bornstein found it was too stripped down and fairly constrained for Android. While improvements such asIsolates as then planned bySun madeprocess isolation infeasible as it broke Android's intra-Device security model. For Dalvik VM, Bornstein particularly took inspiration fromThe Case for Register Machines[6] authored by Brian Davis et al ofTrinity College, Dublin.[8]
Dalvik was open sourced underApache License v2 as rest of theAndroid Open Source Project in 2008.[9]
UnlikeJava Virtual Machines, which arestack machines, the Dalvik VM uses aregister-based architecture that requires fewer, typically more complex, virtual machine instructions. Dalvik programs are written in Java using the Androidapplication programming interface (API), compiled to Java bytecode, and converted to Dalvik instructions as necessary.
A tool calleddx is used to convert Java.class files into the .dex format. Multipleclasses are included in a single .dex file. Duplicatestrings and other constants used in multiple class files are included only once in the .dex output to conserve space. Javabytecode is also converted into an alternativeinstruction set used by the Dalvik VM. An uncompressed .dex file is typically a few percent smaller in size than acompressedJava archive (JAR) derived from the same .class files.[10]
The Dalvik executables may be modified again when installed onto a mobile device. In order to gain furtheroptimizations,byte order may be swapped in certain data, simpledata structures andfunctionlibraries may belinkedinline, and empty class objects may be short-circuited, for example.
Being optimized for low memory requirements, Dalvik has some specific characteristics that differentiate it from other standard VMs:[11]
The design of Dalvik permits a device to run multiple instances of the VM efficiently.[12][13]
Android 2.2 "Froyo" broughttrace-based just-in-time (JIT) compilation into Dalvik, optimizing the execution of applications by continuallyprofiling applications each time they run and dynamicallycompiling frequently executed short segments of their bytecode into nativemachine code. While Dalvikinterprets the rest of application's bytecode, native execution of those short bytecode segments, called "traces", provides significant performance improvements.[14][15][16] The potential traceheads are identified in the front-end of the compiler at the parsing stage and after the bytecode conversion. A translation cache is maintained during the runtime. Multiple traces can be chained to reduce synchronisation between the compiler and the interpreter. The trace is optimized by converting it into theSingle Static Assignment form, enabling optimizations like dead store elimination, variable folding, and inlining getters and setters.[12]
The relative merits ofstack machines versusregister-based approaches are a subject of ongoing debate.[17]
Generally, stack-based machines must useinstructions to load data on the stack and manipulate that data, and, thus, require more instructions than register machines to implement the samehigh-level code, but the instructions in a register machine must encode the source and destination registers and, therefore, tend to be larger. This difference is of importance to VM interpreters, for whichopcode dispatch tends to be expensive, along with other factors similarly relevant tojust-in-time compilation.
Tests performed onARMv7 devices in 2010 byOracle (owner of the Java technology) with standard non-graphical Java benchmarks showed theHotSpot VM ofJava SE embedded to be 2–3 times faster than theJIT-based Dalvik VM ofAndroid 2.2 (the initial Android release that included a JIT compiler).[18] In 2012, academic benchmarks confirmed the factor of 3 betweenHotSpot and Dalvik on the same Android board, also noting that Dalvik code was not smaller than Hotspot.[19]
Furthermore, as of March 2014[update], benchmarks performed on an Android device still show up to a factor 100 between native applications and a Dalvik application on the same Android device.[20][original research?][improper synthesis?] Upon running benchmarks using the early interpreter of 2009, bothJava Native Interface (JNI) and native code showed an order of magnitude speedup.[21]
Dalvik is published under the terms of theApache License 2.0.[22] Some[who?] say that Dalvik is aclean-room implementation rather than a development on top of a standard Java runtime, which would mean it does not inherit copyright-based license restrictions from either the standard-edition or open-source-edition Java runtimes.[23]Oracle and some reviewers dispute this.[24]
On August 12, 2010,Oracle, which acquiredSun Microsystems in April 2009 and therefore owns the rights to Java, sued Google over claimed infringement of copyrights and patents. Oracle alleged that Google, in developing Android, knowingly, directly and repeatedly infringed Oracle's Java-related intellectual property.[25][26][27] In May 2012, the jury in this case found that Google did not infringe on Oracle's patents, and the trial judge ruled that the structure of the Java APIs used by Google was not copyrightable.[28][29] The parties agreed to zero dollars instatutory damages for 9 lines of copied code.[30][31]
The Dalvik runtime is no longer maintained or available [in current versions of Android] and its byte-code format is now used by ART.
{{cite book}}:|journal= ignored (help)The results show that although Androids new JIT is an improvement over its interpreter only implementation, Android is still lagging behind the performance of our Hotspot enabled Java SE Embedded. As you can see from the above results, Java SE Embedded can execute Java bytecodes from 2 to 3 times faster than Android 2.2.
In the JITC mode, however, Dakvik is slower than HotSpot by more than 2.9 times and its generated code size is not smaller than HotSpot's due to its worse code quality and trace-chaining code.
The results show that native C applications can be up to 30 times as fast as an identical algorithm running in Dalvik VM. Java applications can become a speed-up of up to 10 times if utilizing JNI.
The definition of a "clean room" implementation is that the engineers writing the code have no direct exposure to the original, copyrighted material, including code, specifications, and other documentation. That's a problem for Google, as I noted in yesterday's post, because there is substantial evidence that the engineers working on the project had direct access to the copyrighted material.
A major portion of the Oracle's claims are based on 9 lines of code contained within Java.Util.Arrays.rangeCheck(). Here is the code in question:...
