Hirdetés

Keresés

Új hozzászólás Aktív témák

  • modder
    aktív tag

    Hát őh, én úgy olvasom, hogy van a Fordító a (Javac) ami a forrásfájlt bytecode-ra fordítja. Ez tiszta.
    Aztán van a JIT ami egyszer biztosan lefordít mindent! Bytecodra - natív gép kódra fordít.

    Szal a Javac forrásfájt -> bytecode-ra
    és a JIT bytecoderól -> gép kódra

    A JIT elvégzi ezt egyszer. De ha mondjuk a forrásfájlon változtatsz, például az egyik függvényt módosítod a forrásfájlban, akkor a JIT csak azt a függvényhez tartozó bytecode-t fordítja le! És nem az egész .class fájlt.
    (Több helyen többféleképpen magyarazák, én ilyesmit olvasok ki és akkor így a wikipédiás rész is szerintem érthetőbb, mert ott írja, hogy a C/C++ esetén minden egyes fájl újra fordítja, ha van valami változás, még a JIT csak ott, ahol történik, és nem minden egyes fájlt fordít újra)
    Meg ha portolod az alkalmazást, egyszer Linuxon máskor Windowson... akkor biztosan lefut, de csak bytecode-ról gépikódra (Javac mégegyszer nem fut le).

    De ha például én csak az Autó osztályban módosítom a függvényeket, plusz függvényt adok hozzá, akkor a JIT csak ezt az osztályt fordítja le ismét. A motor vagy teherautó osztályt békén hagyja, azt nem fordítja le mégegyszer, mert minek? Abban módosítás nem történt, a bytecode-ja ugyanúgy nézz ki.
    Szerintem inkább ez a lényeg.

    Szóval igen, az amit te mondtál. De én így tudom elképzelni a folyamatot.

    Meg ez .NET is így van, ugyanezt az elvet használja fel és elsőfordításkor minden lassú, még Java-ban is de utána, már nem, érezhetően gyorsabb :)

    Hali, nagyjából jó, amiről beszéltek, de kicsit össze vagytok zavarodva.

    Azt mondjátok, hogy "ha változtatsz a kódon, a JIT csak azt fordítja újra". De ehhez előbb nyilván bytekódot kéne generálni, szóval ez a példa nem jó.

    A jvm interpreterként működik: veszi a bytekódot, és sorról sorra megfeleltetni egy-egy gépi utasításnak vagy jvm-beli utasításnak. Ilyen a PHP is, a python is, az összes interpretált nyelv.

    Amitől a JVM-et Hotspot-JVM-nek hívják az a JIT, ami az alábbi tulajdonságot aknázza ki:
    Általában elmondható, hogy egy program a futása során az idő 90%-át a programrészek (függvények) 10-20%-ában tölti el.

    és ebből jön a JIT működése:
    A JVM futtatja a kódot, statisztikákat készít róla futás közben (profiling). Megtalálja ezt a 10%-ot, ahol a program a futása során a legtöbb időt tölti, majd ezeket a kódokat direktbe lefordítja a célgép gépi kódjára, majd beszúr egy ugrást az eredeti bytekódba (természetesen a memóriában, a .class fájlokba nem ír semmit), hogy most onnantól a gépi kódos rész fut.

    Az optimalizálás pl. abban nyilvánul meg, hogy a JVM látja, mik azok a feltételek, amik sok-sok lefutás után sosem teljesülnek vagy mindig teljesülnek, és úgy fordítja az adott kódrészletet gépi kódra, hogy ezeket a feltételeket alapból igaznak vagy hamisnak veszi
    Például egy if-else ág mindig csak egyik fele igaz, akkor úgy fordítja le a kódot, hogy ki is hagyja a feltételvizsgálatot. Természetesen folyamatosan figyeli ezeket az előfeltételeket, és ha van 1 eset, amikor mégis lefutna a kioptimalizált rész, akkor az eredeti bytekódot futtatja interpretált módban.

    Szó sincs arról, hogy mindent gépi kódra fordít.

    Remélem tisztáztam :)

    Szerk:
    még annyi, hogy ezek mind a program 1-1 futása során történnek. nincsen olyan, hogy a futását befejező program gépi kód részeit valahová elmenti, és ha újra futtatod, akkor azokat betölti. ezek mint just-in-time egy-egy futás alkalmával történő változtatások. ( ezt azért mondom, mert régen én így képzeltem :D)

Új hozzászólás Aktív témák