[Java lista] Oracle Java performance

Molnár Miklós timortinj at freemail.hu
2009. Jún. 22., H, 19:03:10 CEST


Hali,

>Es most olvasom hogy csak a 11g-ben vezettek be a JIT compilert. 

Na álljunk meg egy szóra! ;)

Az Oracle 11g-ben olyan _natív_ ahead compilingot vezettek be, amihez nem
kell külön C fordító és könytár, ami oly sok szivás tárgya volt a korábbi
verziókban (azaz ez a JIT nem az a JIT). Ez a natív ahead compiling teljesen
az Oracle projektje, Aurora néven futott sokáig és fejlődött rendesen az
évek során (azt nem tudom vették-e vagy nulláról megírták-e). 

Az összes ilyen ahead compilernek - mint amilyen a legismertebb jet-compiler
is (www.excelsior-usa.com/jet.html) - közös legnagyobb rákfenéje, hogy
Java-verzió függő, és minden Java kiadáshoz meg kell csinálni (utána kell
menni). Arról a gigantikus méretű szívásról már nem is beszélve, ami az x32
és x64 közötti különbség 'elfedését' célozza meg. Ugye itt arról beszélünk
hogy a Javát hogyan lehet optimális assemblyre fordítani, oprendszerenként
külön-külön. /Az persze egy külön flame tárgya lehetne, hogy érdemes-e ilyen
témába ekkora energiákat fektetni ;)/

Tehát

- Kulcsfontosságú, hogy milyen Oracle verzióról van szó. Tipp: érdemes egy
teszt virtuális gépben a 11g-t kipróbálni, elképesztő sebességgel fog futni
a natív Java, mindenféle hegesztés nélkül. Nekem nagyon jók voltak
legalábbis a tapasztalataim, konkréten leesett az állam, amikor először
nézegettem (nem hittem a szememnek).

- Nekem az az érzésem, hogy Oracle-ben nem triviális jdk/jre-t cserélni
(user szinten), ahead compilingnál tuti (azonnal hátast fog dobni), de
valszeg 'normál' esetben sem. Egy banki környezetben tutifix nem támogatott
az rdbms-beli jre-upgrade.

- El kell dönteni, hogy szükség van-e natív compilingra. Én azt sejtem, hogy
a kérdéses feladatnál nagyságrendi lesz hatékonyságnövekedés. Ez független a
profilingtól: ugyanaz a 'legrosszabb' kód is jobban fog futni Oracle natív
fordítás mellett, különösen akkor, ha processzor és memória-intenzív
alkalmazásról van szó (és nem db-intenzívről). A dolognak _van_ hátránya,
főle egy 9i/10g migrálás esetében: a natív átcuccolás tudhat fáradságos
lenni.

- Oracle 9/10 alatt messze nem könnyű befaragni a natív compilingot: erről
magam is írtam régebben egy hosszú postot ide a levlistára. Horror sztorikat
is tudnék mesélni, de ettől most eltekintenék.

- BTW: érdemes lehet odafigyelni init.ora paraméterekre: java_pool_size és
társai.

- BTW: érdemes lehet odafigyelni Oracle-specifikus java tömbkezelésre.

MM

PS: Szerintem jogos felvetés volt, hogy a témában mi fog történni a
SUN-felvásárlással. ;)



További információk a(z) Javalist levelezőlistáról