[Doc] Java Bytecode <-> .NET IL

[mbravenboer]

Via een weblog op www.servlets.com vond ik een linkje naar een boeiend artikel, wat de intermediate languages van het Java Platform en .NET vergelijkt.

Dit artikel is een wetenschappelijke publicatie en kan daarom als vrij objectief en onafhankelijk worden beschouwd. Het is geschreven door Prof. John Gough. Die als missie van het leven heeft: "To explore strange new compilation optimisations. To go where no compiler-writer has gone before. And now ... to make the Faculty's budget balance!". Dat belooft wat .

Lees het artikel dus maar snel : Postscript, PDF.

Het artikel plaatst het fenomeen IL en bytecode in beide platformen in een goed perspectief, waardoor je wellicht meer zult begrijpen van de gedachten hierachter. Een heel rijtje voorgangers van dergelijke aanpakken worden bijvoorbeeld kort besproken. Je zult zien dat deze technieken al een tijd uitgeprobeerd is in vele varianten...

De auteur schrijft zijn verhaal naar aanleiding van zijn ervaringen bij het schrijven van een compiler voor Component Pascal, in Component Pascal . De compiler bevat twee code-emitters: voor Java Bytecode en .NET IL.

Er wordt in niet al te lastige bewoordingen wat uitgelegd over het executie-model van de beide platformen. Java bytecode wordt kort, leuk, maar duidelijk besproken. Bij de bespreking van de .NET IL komen enkele interessant, subtiele verschillen naar voren met vrij grote gevolgen.

Bij de vergelijking wordt allereerst een interessante opmerking gemaakt over het 'niveau' van de intermediate talen. Vaak is er namelijk al opgemerkt dat het wellicht beter zou zijn voor multi-language support als de beide talen meer low-level zouden zijn. Het belangrijkste argument hiertegen is dat bij het uitvoeren van de code er dan vrijwel geen mogelijkheid meer is voor controle op type-safety. Dit is uiteraard een belangrijke feature in beide VMs.

De belangrijkste conclusie van het stuk is dat het duidelijk is dat de ontwikkelaars van de .NET IL gekozen hebben voor volledige just-in-time compilatie naar native code. De .NET IL kan een stuk minder goed geinterpreteerd worden, wat wellicht een nadeel kan worden voor embedded-systems en de opstarttijd van applicaties.

Op het laatste wordt er nog gesproken over multi-language support naar aanleiding van de Component Pascal compiler. Het belangrijkste punt van kritiek is het ontbreken van reference parameters in de Java bytecode. Dit veroorzaakt voor het compileren veel talen onacceptabele performance problemen.

Het merkwaardige is nu echter dat de .NET IL geen support heeft voor convariante return typen (een return type wat specifieker is dan gespecificeerd door de superklasse of interface). Dit is 1 van de meeste gevraagde features voor de taal Java. In 1.5 zal dit worden toegevoegd aan de taal Java, maar er is nu al een prototype compiler voor Java Generics die coveriante return typen support. Het is wel merkwaardig dat .NET niet gelijk gekozen heeft voor covariante return typen. Wellicht dat de aangekondigde Generics voor C# (die doorgevoerd zullen worden tot de kern van .NET ) in de volgende major update van .NET ook gelijk covariante return typen zullen leveren.

Al met al wel een aardig stuk om te lezen, maar niet erg diepgaand voor een wetenschappelijk stuk naar mijn mening.

_{Ik kan voorlopig niet reageren, dus verwacht even geen antwoorden, discussie of wat dan ook van mij}

[whoami]

Op maandag 08 april 2002 17:18 schreef mbravenboer het volgende:
De .NET IL kan een stuk minder goed geinterpreteerd worden, wat wellicht een nadeel kan worden voor embedded-systems en de opstarttijd van applicaties.

Dat de .NET IL minder goed kan geinterpreteerd worden, ok. Maar wat heeft dit te maken met het minder geschikt zijn voor embedded systems?
_{Misschien staat het antwoord wel in de tekst, maar ik heb nog niet echt tijd gevonden om die te lezen, dat komt wel}

De opstarttijd van de applicaties kan idd meer tijd in beslag nemen dan een de opstarttijd van een Java applicatie vanwege de JIT compile, maar daar staat dan wel weer tegenover dat, eens de applicatie opgestart is, de snelheid beter zal zijn dan de snelheid van de Java - applicatie.

[Scare360]

Inderdaad een leuk artikel.

[mbravenboer]

whoami: Dat de .NET IL minder goed kan geinterpreteerd worden, ok. Maar wat heeft dit te maken met het minder geschikt zijn voor embedded systems?

Het gaat hierbij vooral om de hoge kosten van JIT-compilatike. Het artikel vermeldt dat interpretatie kan zorgen voor een kleinere 'footprint' van de virtual machine. Licht-gewicht implementaties van de JVM zijn volgens de auteur mogelijk, terwijl dit voor .NET IL een stuk lastiger zal zijn. De gedachte hierbij is dat een embedded system geen volledige jitter in huis kan hebben, wat wellicht in veel gevallen teveel ruimte en tijd vraagt. Compileren is immers niet een al te goedkope bezigheid. Heel erg duidelijk komt dit echter niet naar voren. Waarom .NET IL minder geschikt is voor interpretatie komt overigens wel goed uit de verf.

De opstarttijd van de applicaties kan idd meer tijd in beslag nemen dan een de opstarttijd van een Java applicatie vanwege de JIT compile, maar daar staat dan wel weer tegenover dat, eens de applicatie opgestart is, de snelheid beter zal zijn dan de snelheid van de Java - applicatie.

Mwah, waarom denk je dat? Dit is absoluut niet per definitie zo. Er zijn geen grote architectuur-verschillen die deze stelling onderbouwen. Beide systemen gebruiken compilatie naar native code door middel van een jitter. Java gebruikt echter gemixte uitvoering van Java bytecode, waardoor grote delen geinterpreteerd zullen worden en alleen de 'hotspots' naar native code worden omgezet. .NET compileert in principe alles naar native code.

Het mogelijk performance-verschil zal ontstaan omdat het .NET Framework de native code zal gaan cachen. Op dit moment gebeurt dat echter nog niet in de implementatie van .NET. In theorie zou een JVM ook native code kunnen gaan cachen, maar dit zal behoorlijk wat nadelen met zich mee brengen.

Het idee dat Java trager is dan .NET IL komt niet voort uit verschillen in de Java Bytecode maar door de grotere memory-footprint van de huidige JVMs en het niet delen van resources zoals libraries. Zodra de JVM opgeleukt gaat worden met sharing van resources en uitvoering van verschillende applicaties in 1 JVM kan nog een hele interessante strijd ontstaan, waarbij .NET niet per definitie sneller hoeft te zijn.

Feit is wel dat Microsoft verrot goede VMs kan bouwen en ook niet bepaald onkundig is in het implementeren van compilers . Waarschijnlijk zal dat toch sterk in het voordeel van de performance van .NET zijn.

[Verwijderd]

Op maandag 08 april 2002 17:18 schreef mbravenboer het volgende:
Het merkwaardige is nu echter dat de .NET IL geen support heeft voor convariante return typen (een return type wat specifieker is dan gespecificeerd door de superklasse of interface). Dit is 1 van de meeste gevraagde features voor de taal Java. In 1.5 zal dit worden toegevoegd aan de taal Java, maar er is nu al een prototype compiler voor Java Generics die coveriante return typen support. Het is wel merkwaardig dat .NET niet gelijk gekozen heeft voor covariante return typen. Wellicht dat de aangekondigde Generics voor C# (die doorgevoerd zullen worden tot de kern van .NET ) in de volgende major update van .NET ook gelijk covariante return typen zullen leveren.

Ik zie het 'absolute nut' van covariant return types niet echt. Je kunt er semantisch altijd omheen programmeren, zonder dat het echt bizar veel extra werk oplevert. IMHO kun je zelfs een verhaal gaan houden dat het ontbreken van covariant return types de taal ten goede komt. Maar in de overall design is het wellicht een gemis, want talen waar het in zit hebben nu een probleem: overloaded members met verschillende returntypes moeten nu als nieuwe methods worden ge-emit.

[edit]
Over de performance-dip bij het interpreteren van MSIL: die is gigantisch. Als je in VS.net de debugger induikt, dan zie je de overhead van de interpreter vs de JIT-ed code (de jit draait niet tijdens het debugproces).