Jeg (Jesper) fulgte onsdag et indlæg af to svenskere, der arbejder med JRockit og Mission Control. Deres, ret sympatiske, udgangspunkt vat at Java burde kunne køre lige så hurtigt som native kode i et oversat sprog som C++!
For at slå dem skal man være adaptiv og gamble.
At være adaptiv:
Eksempler på gambles:
Hver af de gambles har en gevinst, men en risiko for at de slår fejl. Og fejlene er lidt dyre, men den adaptive runtime fanger disse problemer og retter op. F.eks. hvis der loades en klasse som gør inliningen nævnt ovenfor forkert. Så må koden smides ud og oversættes på ny.
Og vi må heller ikke JIT-oversætte/optimere for meget, vi skal jo maksimere udbyttet af CPU’en.
Så gennemgik de nogle af de cool ting, som man kan med JRockit Mission Control:
De viste hvordan man fandt et memory leak: “Usually, the objects leaked are held in a variable called ‘leak’” – nyttigt tip! Andre gange viste det sig at de kodelinjer, der skulle undgå memory leaks var kommenteret ud. Stor humor.
Så viste de hvordan Mission Control kunne hjælpe med at finde contendede locks og andre pauser. Denne gang var fejlen i deres demo at nogen havde indsat en sleep(200) i deres logningskode. De hævdede at den type fejl forekom rigtig ofte (navnligt i demoer).
Med den mere alvorlige hat på forklarede de at overheadet ved at have alle disse informationer på var under 0,5%. Men så havde en tredjepart med en voldsomt stor installation målt på det for at undersøge om det var forsvarligt at køre i produktion, og de nåede til 0,1 %. De mente selv at hvis man havde en stor serverproces (18GB foreslog de) var det ikke noget problem at hive data ud via Mission Control. Og det matcher jo lige netop mine egne erfaringer . Brug det.
Til gengæld er Method Profileren “useless” – meget ærlige folk! (Den kan profilere kendte procedurer, men hjælper ikke med at finde disse “hot” procedurer, så dem skal man finde selv først)
Plus: God humor, god teknisk indsigt, noget med kød på. Stor lad-mig-få-fingrene-i-det-faktor.
Minus: JRockit er ikke gratis…