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

• modder aktív tag

  #2552

  #2551 Lacces

  2012-03-21 15:56:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  modder

  aktív tag

  #2551 Lacces

  #2551 Lacces

  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 )

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