Dalvik: wat is het, virtuele machine en hoe het werkt

Wat is Dalvik?

Dalvik — virtuele machine met registerarchitectuur, speciaal gemaakt voor het Android-platform. De ontwikkeling begon in 2005 bij het bedrijf van Dan Bornstein, en in 2007 werd het project overgenomen door Google. De eerste commerciële versie van Dalvik verscheen samen met de release van Android 1.0 in 2008.

In tegenstelling tot de standaard Java Virtual Machine (JVM) voert Dalvik geen Java-bytecode uit. De Java-compiler converteert broncode naar class-bestanden, waarna het hulpprogramma dx deze vertaalt naar het formaat Dalvik Executable (DEX). Dit formaat is compacter dan class-bestanden: een applicatie van 10 MB in class-formaat neemt ongeveer 6–7 MB in beslag in DEX.

Geschiedenis van de totstandkoming

Dan Bornstein schreef Dalvik als een project voor besturingssystemen met beperkte middelen. De naam is afkomstig van het IJslandse dorp Dalvík. Google koos voor Dalvik in plaats van JVM vanwege licentiebeperkingen en de noodzaak van diepgaande optimalisatie voor mobiele processors met ARM-architectuur. Het systeem werd snel populair: in 2012 draaiden meer dan 500 miljoen Android-apparaten op Dalvik.

Rol in het Android-ecosysteem

Elke Android-applicatie wordt gestart in een apart proces met een eigen exemplaar van Dalvik VM. Dit zorgt voor gegevensisolatie en bescherming tegen kwaadaardige code op het niveau van het besturingssysteem. Deze benadering combineert de voordelen van virtualisatie met de Linux-sandbox — malware in één applicatie kan geen invloed uitoefenen op naburige processen.

Dalvik-architectuur: registermachine en DEX

Registerarchitectuur van Dalvik verschilt fundamenteel van de stapelarchitectuur van JVM. In plaats van bewerkingen met de bovenkant van de stapel, werkt Dalvik met registers — virtuele cellen binnen de VM. Elke instructie bevat adressen van operandregisters, wat het aantal instructies per bewerking vermindert.

De stapelmachine van JVM gebruikt instructies zoals push, pop en add — voor het optellen van twee getallen zijn drie instructies nodig. Dalvik lost dezelfde taak op met één instructie add-int met drie registers. Volgens Android Open Source Project vermindert de registerarchitectuur van DEX het volume van bytecode gemiddeld met 30% in vergelijking met het stapelgebaseerde class-formaat.

DEX-formaat

DEX-bestand (Dalvik Executable) bevat een gecomprimeerde weergave van alle klassen van de applicatie. De bestandskop bevat een controlesom, sectiegroottes en verschuivingen. De belangrijkste secties zijn pools van strings, types, methodeprototypes, velden en de bytecode zelf. In één DEX-bestand kunnen maximaal 65536 methoden worden opgeslagen (deze beperking is opgeheven met de introductie van multi-dex in Android 5.0).

Voor het converteren van class-bestanden naar DEX wordt het hulpprogramma dx gebruikt, dat deel uitmaakt van de Android SDK Build Tools. Voorbeeld van een opdracht: dx --dex --output=classes.dex myapp.jar. Moderne projecten gebruiken D8 — de opvolger van dx met verbeterde optimalisatie en ondersteuning voor Java 8+ functies.

# Converteren van JAR naar DEX met dx
dx --dex --output=classes.dex myapp.jar

# Moderne versie via D8
d8 --lib android.jar --output dex/ myapp.jar

Zygote: vooraf laden van het framework

Het proces Zygote — het belangrijkste element van de Dalvik-architectuur. Bij het opstarten van het systeem laadt Zygote alle klassen van de Android SDK, opent gedeelde bibliotheken en creëert een pool van vooraf geladen bronnen. Wanneer de gebruiker een applicatie opent, kopieert het systeem het Zygote-proces (fork), waardoor een nieuw exemplaar van Dalvik VM met een reeds gereed framework ontstaat. Dit verkort de opstarttijd van de applicatie van ~2–3 seconden tot 300–500 milliseconden.

JIT-compilatie in Dalvik

JIT (Just-In-Time) — technologie voor het compileren van bytecode naar machine-instructies direct tijdens de uitvoering van de applicatie. In Dalvik analyseert de JIT-compiler de uitgevoerde DEX-code, identificeert veelgebruikte (hot) methoden en compileert deze naar native code voor de CPU.

De keuze voor JIT in plaats van volledige Ahead-Of-Time (AOT)-compilatie in vroege Android-versies was bewust. Mobiele apparaten hadden beperkte flashgeheugen (4–16 GB) — voorafgaande compilatie van alle applicaties zou aanzienlijke ruimte in beslag nemen. Bovendien werkte ROM-geheugen in vroege apparaten langzamer dan RAM, en het lezen van vooraf gecompileerde code kon de prestaties verminderen.

Proces van JIT-compilatie

Wanneer een applicatie wordt gestart, begint Dalvik met het interpreteren van DEX-bytecode. Een speciale profiler houdt bij welke methoden het vaakst worden aangeroepen. Na het overschrijden van de drempel (meestal ~200 aanroepen) converteert de JIT-compiler de methode naar machinecode en cachet deze in het RAM. Volgende aanroepen gebruiken de reeds gecompileerde versie zonder hercompilatie.

// Voorbeeld van een hot-methode die JIT zal compileren
public class Calculator {
    public int sumArray(int[] arr) {
        int total = 0;
        for (int i = 0; i < arr.length; i++) {
            total += arr[i];
        }
        return total;
    }
}

Prestaties van JIT

Volgens Google I/O 2013 versnelde de implementatie van JIT in Android 2.2 Froyo de uitvoering van applicaties gemiddeld 2–5 keer in vergelijking met pure interpretatie. JIT voegt echter een vertraging toe bij de eerste start: de applicatie heeft 3 tot 10 seconden nodig om op te warmen en hot-methoden te compileren. Na het opwarmen stabiliseren de prestaties zich op een niveau dat dicht bij native code ligt.

Dalvik vs JVM: belangrijkste verschillen

Dalvik verschilt van JVM op verschillende fundamentele parameters. Ten eerste — architectuur: JVM is stapelgebaseerd, Dalvik is registergebaseerd. Ten tweede — bytecode-formaat: JVM gebruikt class-bestanden, Dalvik gebruikt DEX. Ten derde — geheugenbeheer: Dalvik is geoptimaliseerd voor beperkt RAM van mobiele apparaten.

Beide benaderingen hebben sterke punten. Stapelgebaseerde JVM heeft minder ruimte nodig voor het opslaan van instructies — elke instructie is korter omdat operanden impliciet van de stapel worden gehaald. Registergebaseerde Dalvik voert minder instructies per bewerking uit, wat processortijd bespaart en energieverbruik verlaagt. Voor mobiele apparaten op batterijvoeding is dit cruciaal.

Licentieaspecten

De keuze voor Dalvik in plaats van JVM was ook te wijten aan licentiëring. Oracle bezit de rechten op Java SE en JVM, en Google wilde licentiekosten vermijden. Het creëren van een eigen VM met een alternatief bytecode-formaat stelde Android in staat zich onafhankelijk van Oracle te ontwikkelen. Dit geschil leidde tot een jarenlang juridisch proces Oracle vs Google (2010–2021), dat eindigde in het voordeel van Google.

DEX-formaat en het hulpprogramma dx

DEX (Dalvik Executable) — binair formaat dat de gecompileerde code van een Android-applicatie bevat. Elk DEX-bestand begint met een header, gevolgd door secties: stringconstanten (string_ids), types (type_ids), methodeprototypes (proto_ids), velden (field_ids), methoden (method_ids), klassendefinities (class_defs) en het gegevensgebied (data).

Het hulpprogramma dx converteert Java class-bestanden naar een of meerdere DEX-bestanden. Het werkingsalgoritme omvat deduplicatie van constanten — identieke strings of types worden één keer opgeslagen en via een index gerefereerd. Dit vermindert de uiteindelijke grootte aanzienlijk. In moderne projecten is dx vervangen door D8 (verschenen in Android Studio 3.1), die 2–3 keer sneller werkt en Java 8 desugaring ondersteunt.

// Voorbeeld van gedecompileerde DEX-bytecode via dexdump
// Broncode: return a + b;
@Ldalvik/annotation/Code;
    registers: 3
    add-int v0, v1, v2
    return v0

Multi-dex: het overwinnen van de limiet van 65536

De beperking van het DEX-formaat tot 65536 methoden (limiet van de 16-bits index) werd een serieus probleem voor grote applicaties. De oplossing kwam in Android 5.0: ondersteuning voor multi-dex stelt een applicatie in staat meerdere DEX-bestanden te bevatten. Het hoofdbestand classes.dex bevat de ingangspunten, en aanvullende bestanden classes2.dex, classes3.dex enzovoort bevatten de rest van de code. Configuratie van multi-dex wordt ingeschakeld in build.gradle met de regel multiDexEnabled true.

Geheugenbeheer en garbage collection

Garbage collection in Dalvik is geïmplementeerd als een generationele verzamelaar met markeren en opschonen (mark-and-sweep). Het geheugen is verdeeld in twee hoofdgebieden: Heap (hoop) voor objecten en Stack (stapel) voor primitieven en referenties. Wanneer de Heap vol raakt, onderbreekt Dalvik alle threads (STW — Stop-The-World), markeert bereikbare objecten en maakt onbereikbare objecten vrij.

Tot Android 2.2 gebruikte Dalvik een single-threaded verzamelaar met pauzes tot 100–200 ms. In Android 2.3 Gingerbread verscheen een concurrerende verzamelaar, die typische pauzes terugbracht tot 5–10 ms. En in Android 4.0 Ice Cream Sandwich werd een verzamelaar met incrementele opschoning toegevoegd — Concurrent Mark and Sweep (CMS).

Geheugenlekken

Een typisch probleem van Dalvik-applicaties — geheugenlekken via statische referenties naar Activity. Als een statisch veld een referentie naar Context of View opslaat, kan de garbage collector Activity niet vrijgeven, zelfs niet na het sluiten van het scherm. Hulpmiddelen zoals Eclipse MAT en LeakCanary helpen bij het opsporen van dergelijke lekken: ze analyseren de Heap-dump en tonen de referentieketens die het object vasthouden.

// Voorbeeld van geheugenlek via statische referentie
public class Utils {
    private static Context context;

    public static void init(Context ctx) {
        context = ctx; // Houdt Activity vast na finish()
    }
}

Beperkingen van Dalvik en overgang naar ART

Ondanks het succes had Dalvik een aantal nadelen. JIT-compilatie had tijd nodig om op te warmen — de eerste seconden van de applicatie waren langzamer. Bovendien verbruikte JIT energie van de processor tijdens het compileren, wat de batterijduur verkortte. Met de toename van de prestaties van mobiele apparaten en de toename van de ingebouwde geheugencapaciteit nam de behoefte aan JIT af.

In Android 4.4 KitKat introduceerde Google ART (Android Runtime) als experimentele vervanging voor Dalvik. Vanaf Android 5.0 Lollipop werd ART de enige runtime-omgeving. Het belangrijkste verschil — AOT-compilatie: in plaats van compilatie tijdens runtime worden alle applicaties bij installatie gecompileerd naar machinecode. Dit elimineerde opwarmvertragingen en verbeterde de energie-efficiëntie.

Achterwaartse compatibiliteit

De overgang van Dalvik naar ART was transparant voor ontwikkelaars: beide omgevingen voeren dezelfde DEX-bytecode uit. Applicaties die voor Dalvik zijn gebouwd, werken op ART zonder hercompilatie — system_server compileert ze bij installatie naar native code. Uitzondering is code die reflectie gebruikt om toegang te krijgen tot interne leden van Dalvik VM: dergelijke code kon kapotgaan op ART vanwege veranderingen in de interne architectuur.