Dalvik (software)

Dalvik, named after a town in Iceland by its creator Dan Bornstein,{{cite video |url=https://www.youtube.com/watch?v=FO1Xe7bF2VY |via=YouTube |work=InfoQ |date=29 Sep 2015 |title= Live Q&A with Dan Bornstein, Creator of the Dalvik VM }} was designed for embedded devices with very low RAM and CPU{{cite video |url=https://www.youtube.com/watch?v=ptjedOZEXPM |via=YouTube |work=Google |date=4 Jun 2008 |title=Google I/O 2008 - Dalvik Virtual Machine Internals }} to run Java code, and eventually support C++ for "heavy-duty apps" and JavaScript 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 with J2ME on Sidekick at Danger, Bornstein found it was too stripped down and fairly constrained for Android. While improvements such as Isolates as then planned by Sun made process isolation infeasible as it broke Android's intra-Device security model. For Dalvik VM, Bornstein particularly took inspiration from The Case for Register Machines{{r|danama}} authored by Brian Davis et al of Trinity College, Dublin.{{cite book |doi=10.1145/858570.858575 |chapter-url=http://eprints.maynoothuniversity.ie/10190/1/KC-Case-2005.pdf |title=Proceedings of the 2003 workshop on Interpreters, virtual machines and emulators |archive-url=https://web.archive.org/web/20240201175416/https://www.scss.tcd.ie/David.Gregg/papers/Gregg-SoCP-2005.pdf |archive-date=1 Feb 2024 |date=8 Jun 2003 |journal=Association for Computing Machinery |last1=Davis |first1=Brian |last2=Beatty |first2=Andrew |last3=Casey |first3=Kevin |last4=Gregg |first4=David |last5=T Waldron |first5=John |chapter=The case for virtual register machines |pages=41–49 |isbn=1-58113-655-2 }}

Dalvik was open sourced under Apache License v2 as rest of the Android Open Source Project in 2008.{{cite magazine |title=Android SDK Open For Code |url=https://www.wired.com/2007/11/android-sdk-ope/ |archive-url=https://archive.today/20240131161213/https://www.wired.com/2007/11/android-sdk-ope/ |archive-date=31 January 2024 |date=12 Nov 2007 |magazine=WIRED |last1=Beschizza |first1=Rob}}

File:ART view.png architectures]]

Unlike Java Virtual Machines, which are stack machines, the Dalvik VM uses a register-based architecture that requires fewer, typically more complex, virtual machine instructions. Dalvik programs are written in Java using the Android application programming interface (API), compiled to Java bytecode, and converted to Dalvik instructions as necessary.

A tool called dx is used to convert Java .class files into the .dex format. Multiple classes are included in a single .dex file. Duplicate strings and other constants used in multiple class files are included only once in the .dex output to conserve space. Java bytecode is also converted into an alternative instruction set used by the Dalvik VM. An uncompressed .dex file is typically a few percent smaller in size than a compressed Java archive (JAR) derived from the same .class files.{{cite web

| url=http://sites.google.com/site/io/dalvik-vm-internals/2008-05-29-Presentation-Of-Dalvik-VM-Internals.pdf?attredirects=0

| title=Presentation of Dalvik VM Internals

| first=Dan

| last=Bornstein

| date=2008-05-29

| access-date=2010-08-16

| format=PDF

| page=22

| archive-date=2017-04-16

| archive-url=https://web.archive.org/web/20170416064828/https://sites.google.com/site/io/dalvik-vm-internals/2008-05-29-Presentation-Of-Dalvik-VM-Internals.pdf?attredirects=0

| url-status=dead

}}

The Dalvik executables may be modified again when installed onto a mobile device. In order to gain further optimizations, byte order may be swapped in certain data, simple data structures and function libraries may be linked inline, 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:{{cite web

| url=http://blogs.sun.com/jrose/entry/with_android_and_dalvik_at

| title=with Android and Dalvik at Google I/O

| last=Rose

| first=John

| date=2008-05-31

| access-date=2008-06-08

| archive-url=https://web.archive.org/web/20080604070631/http://blogs.sun.com/jrose/entry/with_android_and_dalvik_at

| archive-date=2008-06-04

| url-status=dead

}}

• The VM was slimmed down to use less space.
• The constant pool has been modified to use only 32-bit indices to simplify the interpreter.
• Standard Java bytecode executes 8-bit stack instructions. Local variables must be copied to or from the operand stack by separate instructions. Dalvik instead uses its own 16-bit instruction set that works directly on local variables. The local variable is commonly picked by a 4-bit "virtual register" field. This lowers Dalvik's instruction count and raises its interpreter speed.

The design of Dalvik permits a device to run multiple instances of the VM efficiently.{{r|ramanan}}{{cite web

| url=http://developer.android.com/guide/basics/what-is-android.html

| title=What is Android?

| author=((Google))

| date=2009-04-13

| access-date=2009-04-19

| archive-url=https://web.archive.org/web/20090627025128/https://developer.android.com/guide/basics/what-is-android.html

| archive-date=2009-06-27

}}

Android 2.2 "Froyo" brought trace-based just-in-time (JIT) compilation into Dalvik, optimizing the execution of applications by continually profiling applications each time they run and dynamically compiling frequently executed short segments of their bytecode into native machine code. While Dalvik interprets the rest of application's bytecode, native execution of those short bytecode segments, called "traces", provides significant performance improvements.{{cite web

| url = http://www.android-app-developer.co.uk/android-app-development-docs/android-jit-compiler-androids-dalvik-vm.pdf

| title = A JIT Compiler for Android's Dalvik VM

| date = May 2010

| access-date = March 18, 2015

| author1 = Ben Cheng

| author2 = Bill Buzbee

| website = android-app-developer.co.uk

| pages = 5–14

| archive-url = https://web.archive.org/web/20151106221110/http://www.android-app-developer.co.uk/android-app-development-docs/android-jit-compiler-androids-dalvik-vm.pdf

| archive-date = 2015-11-06

| url-status = dead

}}{{cite web

| url = http://www.androidcentral.com/google-android-developer-explains-more-about-dalvik-and-jit-froyo

| title = Google Android developer explains more about Dalvik and the JIT in Froyo

| date = May 26, 2010 | access-date = July 8, 2014

| author = Phil Nickinson | website = androidcentral.com

| archive-url = https://web.archive.org/web/20140714171809/http://www.androidcentral.com/google-android-developer-explains-more-about-dalvik-and-jit-froyo

| archive-date = 2014-07-14

}}{{cite web |url= http://www.androidpolice.com/2010/05/11/exclusive-androidpolice-coms-nexus-one-is-running-android-2-2-froyo-how-fast-is-it-compared-to-2-1-oh-only-about-450-faster/ | title= Nexus One Is Running Android 2.2 Froyo. How Fast Is It Compared To 2.1? Oh, Only About 450% Faster |date= 2010-05-13 |access-date= 2010-05-21}} The potential trace

heads 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 the Single Static Assignment form, enabling optimizations like dead store elimination, variable folding, and inlining getters and setters.{{cite web |title=JIT through the ages |url=http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_Ramanan_JIT.pdf |last=Ramanan |first=Neeraja | date=12 Dec 2011 }}

File:Motorola RAZR XT910.jpg

The relative merits of stack machines versus register-based approaches are a subject of ongoing debate.{{cite web

| url= http://www.usenix.org/events/vee05/full_papers/p153-yunhe.pdf

| title= Virtual Machine Showdown: Stack Versus Registers

| first4= M. Anton |last4= Ertl

| first1= Yunhe |last1= Shi

| first2= David |last2= Gregg

| first3= Andrew |last3= Beatty

| date= 2005-06-11

| access-date= 2009-12-22}}

Generally, stack-based machines must use instructions to load data on the stack and manipulate that data, and, thus, require more instructions than register machines to implement the same high-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 which opcode dispatch tends to be expensive, along with other factors similarly relevant to just-in-time compilation.

Tests performed on ARMv7 devices in 2010 by Oracle (owner of the Java technology) with standard non-graphical Java benchmarks showed the HotSpot VM of Java SE embedded to be 2–3 times faster than the JIT-based Dalvik VM of Android 2.2 (the initial Android release that included a JIT compiler).{{cite web

|url = http://blogs.oracle.com/javaseembedded/entry/how_does_android_22s_performance_stack_up_against_java_se_embedded

|title = Java SE Embedded Performance Versus Android 2.2

|publisher = Oracle Corporation

|first = Bob

|last = Vandette

|date = 2010-11-22

|quote = 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.

|access-date = 2011-09-04

|archive-url = https://web.archive.org/web/20110628210207/http://blogs.oracle.com/javaseembedded/entry/how_does_android_22s_performance_stack_up_against_java_se_embedded

|archive-date = 2011-06-28

|url-status = dead

}} In 2012, academic benchmarks confirmed the factor of 3 between HotSpot and Dalvik on the same Android board, also noting that Dalvik code was not smaller than Hotspot.{{cite book

| publisher=Association for Computing Machinery

|author1=Hyeong-Seok Oh | title= Proceedings of the 10th International Workshop on Java Technologies for Real-time and Embedded Systems - JTRES '12

| pages=115

|author2=Beom-Jun Kim |author3=Hyung-Kyu Choi |author4=Soo-Mook Moon | year= 2012

| quote=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.

| doi=10.1145/2388936.2388956

| isbn=9781450316880

|s2cid=36316611 }}

Furthermore, {{As of|2014|3|lc=yes}}, 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.{{cite web

| url= http://www.eembc.org/andebench/

| title=Top AndEBench Scores

| publisher=www.eembc.org

| access-date= 2014-03-23}}{{OR|date=June 2014}}{{synthesis inline|date=June 2014}} Upon running benchmarks using the early interpreter of 2009, both Java Native Interface (JNI) and native code showed an order of magnitude speedup.{{cite book

| volume=7

| pages=381–392

| date= 2009-04-29

| quote=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.

| doi=10.1007/978-3-642-01802-2_28

|last1 = Batyuk|first1 = Leonid| last2=Schmidt

| first2=Aubrey-Derrick

| last3=Schmidt

| first3=Hans-Gunther

| last4=Camtepe

| first4=Ahmet

| last5=Albayrak

| first5=Sahin

| title=MobileWireless Middleware, Operating Systems, and Applications

| chapter=Developing and Benchmarking Native Linux Applications on Android

| series=Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering

| bibcode=2009mmos.book..381B

| s2cid=12131309

| isbn=978-3-642-01801-5

}}

{{main|Oracle v. Google}}

Dalvik is published under the terms of the Apache License 2.0.{{cite web |url=http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=NOTICE;hb=HEAD |title=Downloading the Source Tree - Android Open Source |publisher=Android.git.kernel.org |access-date=2012-06-07 |url-status=dead |archive-url=https://web.archive.org/web/20090417091524/http://android.git.kernel.org/?p=platform%2Fdalvik.git |archive-date=2009-04-17 }} Some {{who?|date=February 2023}} say that Dalvik is a clean-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.{{Cite magazine|url=https://www.wired.com/2012/04/google-oracle-experts|title=Google and Oracle 'Experts' Clash over Android's Java Mimic|magazine=Wired|last1=Garling|first1=Caleb}}

Oracle and some reviewers dispute this.{{cite web

| url=https://www.zdnet.com/article/the-real-history-of-java-and-android-as-told-by-google/

| title=The real history of Java and Android, as told by Google

| author=Ed Bott

| publisher=ZDNet

| quote=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.

| date=September 8, 2011

| access-date=2011-11-27}}

On August 12, 2010, Oracle, which acquired Sun 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.{{cite web| url=http://www.digitaltrends.com/mobile/oracle-sues-google-over-java-in-android-devices/

| title=Oracle Sues Google Over Java in Android Devices

| publisher=digitaltrends.com

| date=2010-08-13

| access-date=2011-08-08}}{{cite web

| url= http://www.computerworld.com/s/article/9180678/Update_Oracle_sues_Google_over_Java_use_in_Android?taxonomyId=13

| title=Oracle sues Google over Java use in Android

| author=James Niccolai

| date=2010-08-12

| work = Computerworld

| access-date=2010-08-13

}}{{cite web

| title = Oracle Sues Google Over Android Java Use

| author = Mark Hachman

| date = 2010-08-13

| url = https://www.pcmag.com/article2/0,2817,2367761,00.asp

| work = PC Magazine

| publisher = Ziff Davis}} 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.{{cite web | url=https://www.zdnet.com/article/jury-clears-google-of-infringing-on-oracle-patents/ | title=Jury clears Google of infringing on Oracle's patents | author = Josh Lowensohn | work=ZDNet | date = May 23, 2012 | access-date=2012-05-25}}

{{cite web

| title = Google wins crucial API ruling, Oracle's case decimated

| url = https://arstechnica.com/tech-policy/2012/05/google-wins-crucial-api-ruling-oracles-case-decimated/

| author = Joe Mullin

| work = Ars Technica

| date = May 31, 2012

| access-date = 2012-06-01}} The parties agreed to zero dollars in statutory damages for 9 lines of copied code.{{cite web

| title = Oracle agrees to 'zero' damages in Google lawsuit, eyes appeal

| url = http://www.computerworld.com/s/article/9228298/Oracle_agrees_to_zero_damages_in_Google_lawsuit_eyes_appeal

| access-date = 2012-06-23

| first = James

| last = Niccolai

| date = June 20, 2012

| archive-date = 2023-04-01

| archive-url = https://web.archive.org/web/20230401114703/https://www.computerworld.com/article/2722368/oracle-agrees-to--zero--damages-in-google-lawsuit--eyes-appeal.html

| url-status = dead

}}

{{cite web

| title = Update on the Oracle Versus Google Trial

| quote=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:...

| url = http://www.xda-developers.com/android/update-on-the-oracle-versus-google-trial/

| access-date = 2013-01-18

| author = Adam Outler

| date = May 16, 2012

| archive-url = https://web.archive.org/web/20130516201945/http://www.xda-developers.com/android/update-on-the-oracle-versus-google-trial/

| archive-date=2013-05-16}}

{{Portal|Free and open-source software}}

• Android Runtime
• Android software development
• Application virtualization
• Comparison of application virtualization software
• Comparison of Java and Android API
• JEB decompiler – a Dalvik (DEX and APK) decompiler
• Dalvik Turbo virtual machine – a proprietary alternative Dalvik implementation

{{Reflist|30em}}

• [https://source.android.com/devices/tech/dalvik/dalvik-bytecode.html Dalvik bytecode] – official Android documentation of the instruction set
• [https://source.android.com/devices/tech/dalvik/dex-format.html Dex Executable format] – official Android documentation
• {{YouTube|id=Ls0tM-c4Vfo|title=A JIT Compiler for Android's Dalvik VM}}, Google I/O 2010, by Ben Cheng and Bill Buzbee
• [http://sites.google.com/site/io/dalvik-vm-internals Dalvik VM Internals] {{Webarchive|url=https://web.archive.org/web/20100301173652/http://sites.google.com/site/io/dalvik-vm-internals |date=2010-03-01 }}, Google I/O 2008, by Dan Bornstein
• [http://johnkoenig.com/the-800-million-dollar-question-whats-the-difference-between-trademark-and-copyright/ The $800 Million Dollar Question: What’s the Difference Between Trademark and Copyright?]

{{Android}}

{{Virtualization software}}

{{DEFAULTSORT:Dalvik (Software)}}

Category:Android (operating system)

Category:Discontinued Java virtual machines

Category:Register-based virtual machines

Category:Bytecodes