JRockit från Appeal Virtual Machines, en svensk JVM specialanpassad för servrar. Kan det verkligen vara någonting? Kan en sådan produkt hävda sig i konkurrensen mot bransch jättar som Sun Microsystems och IBM? I denna artikel presenteras grundidéerna i produkt- en och vad som skiljer JRockit från vanliga JVM:er.
Innan arbetet med JRockit inleddes gjordes en undersökning av vad ut- vecklare av serverapplikationer egentligen ville ha för egenskaper i en JVM. Denna lista har legat till grund för det som är JRockit idag:
- Pålitlighet/Robusthet (24×7)
- Skalbarhet
- Korta pauser
- Kodprestanda
Pålitlighet och möjlighet att kunna köra sina system dag ut och dag in, vecka efter vecka, var den i särklass mest efterfrågade egenskapen i en server-JVM. För att, som ett litet företag, kunna erbjuda detta är det Appeals målsättning att se till att så många som möjligt får möjlighet att testa JRockit och att bugrapporter besvaras och åtgärdas så snart det går.
Skalbarhet eller möjligheten att kunna hantera en stor mängd samtidiga användare och att utnyttja tillagd maskin- vara så effektivt som möjligt står näst högst upp på listan.
Trea på listan är korta pauser. Allt för många serversystem lider fortfarande av skräpsamlingspauser som är flera
sekunder långa.
Vad som kanske är mest anmärkningsvärt med denna lista är att kodprestanda kom först på fjärdeplats. Det är ett av de mindre problem man har i ett serversystem, något som kanske är värt att komma ihåg när man står i valet mellan en svårdebuggad men snabb C++ lösning mot java.
JRockit – en JVM med siktet inställt på mer än bara kod och skräpsamling
Sun och IBM ser på JVM:en som någonting vars uppgift är att exekvera kod och att skräpsamla, d v s kodexekvering och minneshantering är de områden som man optimerar. JRockit har en annan filosofi: Ett av de viktigaste underliggande designvalen i JRockit är att JVM:en inte bara ska kunna förbättra kodexekvering och minneshantering, utan att även trådhantering, fil och nätkommunikation ska ingå bland de områden JRockit optimerar.
Varför skiljer sig då JRockits optimerings- områden från de andra JVMernas? För att förstå detta måste vi gå tillbaka i tiden till Javas födelse: När Sun i början av 1997 gjorde en analys av prestandaproblemen, kom man fram till att för en godtycklig applikation låg 75% av tiden i kodexekvering och 20% av tiden i skräpsamling. Naturligtvis valde man att satsa på optimerad kodexekvering och skräpsamling i sin kommande JVM, HotSpot. Ett problem med analysen var att de applikationer man undersökte var typiska klientapplikationer. Användandet av Java på serversidan låg fortfarande i sin vagga.
JRockit har tagit fasta på att fördelningen mellan de olika områdena på serversidan inte är alls likadan. En typisk serverapp- likation kan tillbringa 25% av sin tid i kod, 25% av tiden i skräpsamling, 25% av tiden i trådhantering och de resterande 25% med nätverkskommunikation. Att inte optimera tråd- och nätverkshantering för sådana system resulterar i att man bara kan förbättra 50% av applikationen, och då teoretiskt maximalt halvera exekveringstiden. Genom att ge JVM:en bättre kontroll över tråd- och nätverkskom- munikationen kan dessa områden väsentligt snabbas upp utan förbättringar i det underliggande operativsystemet.
Vad det gäller tråd- och näthantering har man på Sun fortfarande åsikten att de största förbättringarna inom dessa om- råden inte kommer ifrån JVM:en utan från utvecklingen inom operativsystemavdel- ningarna.
Dynamisk Optimering
Dynamisk optimering är ett annat av huvudkoncepten i JRockit. Dynamisk optimering innebär att det körande programmet förbättras under körningens gång, JVMen anpassar exekvering av programmet till hur det används och vilka delar som används. Dynamisk optimering möjliggör ointuitivt nog högre exekveringshastigheter än traditionell kompilering för stora komplexa system. För att förstå varför måste vi först förstå vilka egenheter stora system har. För det första så är systemen ofta flerlagersarkitekturer, en nödvändighet för att skapa abstraktion och få överblick över systemen.
Det är bra för människans förståelse av systemet på en övergripande nivå, men för datorn som exekverar systemet leder det till att man måste passera genom fler lager, vilket tar mer tid. För det andra så bygger man vanligtvis nya system ovanpå andra system (t ex applikationsservrar) eller med hjälp av andra komponenter (skrivna av andra eller i tidigare system). I allmänhet är dessa komponenter generella, dvs de är byggda för att lösa en mängd olika uppgifter, varav endast en del utnyttjas i det aktuella systemet. Givetvis är det bra att systemutvecklare lär sig att inte hela tiden uppfinna hjulet på nytt, men ur en prestandasynvinkel så skulle antagligen systemet exekvera snabbare om man använde mer specialiserade komponenter.
Dessvärre kan statisk kompilering inte hjälpa till speciellt mycket om språket är dynamiskt som t ex Java: det är svårt, för att inte säga omöjligt att veta vilka komponenter som kommer att finnas i systemet innan man startat det. Detta på grund av att Java tilllåter ny funktionalitet att laddas in under körningens gång (klassladdning). Genom dynamisk optimering kan JVM:en under körningen skala bort de lager som bara fyller en abstraktionsfunktion för människan och dessutom kan de komponenter som används på ett specifikt ställe i systemet specialiseras till hur de används på det stället. Dynamisk optimering ger alltså, åtminstone i teorin, människan en möjlighet att bevara i stort sett all abstraktion utan att förlora allt för mycket prestanda. Kritik har dock riktats mot att själva optimeringsprocessen tar tid från exekveringen. Detta kan förvisso vara sant men om optimeringar görs under systemets första tio minuters drifttid och systemet kommer att vara uppe i flera veckor i streck är det en försumbar kostnad och dessutom kan man tänka sig att det optimeringsarbete som görs sparas för att återanvändas.
Konfigurerbarhet
Ytterligare en unik filosofi hos JRockit som andra JVM-tillverkare först på senare tid börjat titta på är baserad på det faktum att ingen applikation är den andra lik. Det finns inga patentlösning. Finns inte en perfekt konfiguration av en JVM som kommer att fungera lika bra för alla applikationer.
JVM:ens konfiguration måste kunna anpassas till olika applikationer. Detta kan göras på två sätt:
1) JVM:en analyserar applikationen under körning och justerar sina parametrar för att kunna exekvera applikationen så effektivt som möjligt. En del av denna process är den dynamiska optimeringen som beskrevs ovan,
2) Utvecklarna av systemet kan själva konfigurera JVM:en både vid uppstart och under körningen. Konfigureringen under körningen ska kunna göras ifrån Java.
Tanken är att JVM:en på bästa sätt ska anpassa sig men även bli anpassad till applikationen för högsta möjliga pre- standa.
Installera och testa JRockit
Den nyfikna läsaren har nu börjat fråga sig ”kan jag jag pröva JRockit”? Ja, du kan ladda ned en fullfjädrad version för Solaris, Linux eller Win2000 från http:// http://www.jrockit.com.
Framtiden
Vad händer med JRockit i framtiden. Ett av de viktigaste områdena man arbetar med är licensiering: att få applikations- servertillverkarna (BEA Weblogic, IBM Websphere, ATG Dynamo, Orion m.fl.) att ta upp JRockit som en rekommenderad JVM för sina applikationsservrar.
För den första versionen av JRockit satsade man på att bli avsevärt mycket snabbare än de andra JVM:erna inom tråd- och nätverksprestanda, någonting man lyckades med. Detta visades genom den oslagbara skalbarhet man lyckas uppnå på det välkända Volano-testet: http:// http://www.volano.com/report.html .
Vad det gällde kod och skräpsamlings- prestanda var man dock för den första versionen av JRockit tvungna att inse att avståndet till de andra JVM:erna var för stort. Därför pågår nu intensivt arbete inom dessa områden för att bli bättre än de andra även här. Lyckas man? Svaret återstår att se senare i år.
Originally published in JayView.
Tags: java
Tumblelight 
Leave a Reply