Java virtuala maŝino ( JVM) estas abstrakta komputikmaŝino kiu ebligas komputilon prizorgi Java programon.
Ekzistas tri nocioj de la JVM: specifo, efektivigo, kaj kazo.
La specifo estas dokumento kiu formale priskribas kio estas postulata de JVM-efektivigo.
Havi ununuran specifon certigas ke ĉiuj efektivigoj estu interoperacieblaj.
JVM-efektivigo estas komputila programo kiu renkontas la postulojn de la JVM-specifo.
Kazo de JVM estas efektivigo kuranta en procezo kiu ruligas komputilan programon kompilis en Java Bajtkodon.
#000001
1 Sekura plenumo de malproksima kodo
Bajtkoda interpretilo kaj ekzakte ĝustatempa kompililo
#000005
1 Sekura plenumo de malproksima kodo
#000006
La Java virtuala maŝino estas abstrakta (virtuala) komputilo difinita per specifo.
Tiu specifo preterlasas efektivigdetalojn kiuj ne estas esencaj certigi kunfunkcieblecon: la memorenpaĝigo de rultempaj datenareoj, la rubkolekto-algoritmo uzita, kaj ajna interna Optimumigo de la Java virtuala maŝininstrukciaĵo (sia traduko en maŝinkodon).
La ĉefkialo de tiu preterlaso devas ne unnecessar limigi efektivigantojn.
Ĉiu Java aplikaĵo povas esti prizorgita nur ene de iu konkreta efektivigo de la abstrakta specifo de la Java virtuala maŝino.
#000007
Komencante kun Java Platform, Standard Edition (Java Platform, Normeldono) (J2SE) 5.0, ŝanĝoj al la JVM-specifo estis evoluigitaj sub la Java Komunuma Procezo kiel JSR 924.
Aktuale en 2006 [ĝisdatigo] , ŝanĝoj al specifo apogi ŝanĝojn proponis al la klasa dosierformato (JSR 202) [3] estas faritaj kiel ripareldono de JSR 924.
La specifo por la JVM estis publikigita kiel la blua libro, [4] La antaŭparolŝtatoj:
#000008
Ni celas ke tiu specifo devus sufiĉe dokumenti la Javan Virtualan Maŝinon por fari eblajn kongruajn pura-ĉambrefektivigojn.
Orakolo disponigas testojn kiuj konfirmas la bonordan operacion de efektivigoj de la Java Virtuala Maŝino.
#000009
Unu el la JVMoj de Oracle estas nomita Retpunkto, la alia, heredis de BEA Systems estas JRockit.
Pura-ĉambraj Java efektivigoj inkludas Kaffe kaj IBM J9.
Orakolo posedas la Java varmarkon kaj povas permesi al ĝia uzo atesti efektivigseriojn kiel tute kongruaj kun la specifo de Oracle.
#000010
Unu de la organizaj unuoj de JVM-bajtkodo estas klaso.
Klasŝargilo kiun efektivigo devas povi rekoni kaj ŝarĝi io ajn kiu harmonias kun la Java klaso dosierformaton.
Ĉiu efektivigo estas libera rekoni aliajn binarajn formojn krom klas dosieroj, sed ĝi devas rekoni klas dosierojn.
#000011
La klasŝargilo elfaras tri bazajn agadojn en tiu strikta sinsekvo:
#000012
Ŝarĝado: trovaĵoj kaj importado la binaraj datenoj por tipo
Ligado: prezentas konfirmon, preparon, kaj (laŭvole) rezolucionKonfirmo: certigas la korektecon de la importita tipo
Preparo: asignas memoron por klasvariabloj kaj initializing la memoron al normalvaloroj
Rezolucio: transformas simbolajn referencojn de la tipo en rektajn referencojn.
Inicialigo: alvokas Java kodon kiu initialigas klasvariablojn al iliaj bonordaj startvaloroj.
#000013
Konfirmo: certigas la korektecon de la importita tipo
Preparo: asignas memoron por klasvariabloj kaj initializing la memoron al normalvaloroj
Rezolucio: transformas simbolajn referencojn de la tipo en rektajn referencojn.
#000014
Ĝenerale, ekzistas du specoj de klasŝargilo: botŝekla klasŝargilo kaj uzanto difinis klasŝargilon.
#000015
Ĉiu Java virtuala maŝinefektivigo havendaĵo botŝeklan klasŝargilon, kapablan je ŝarĝadaj fidindaj klasoj.
La Java virtuala maŝinspecifo ne precizigas kiel klasŝargilo devus lokalizi klasojn.
#000016
La JVM funkciigas sur primitivaj valoroj (entjeroj kaj glitkomaj nombroj) kaj referencoj.
La JVM estas principe 32-bita maŝino.longkajdoubletipoj, kiuj estas 64-bits, estas apogitaj indiĝene, sed konsumas du ekzemplerojn de stokado en la lokaj variabloj aŭ operaciantostako de kadro, ĉar ĉiu unuo estas 32 bitoj.boolean, byte, short, kajchartipoj estas tute signo-plilongigitaj (kromcharkiu estas nul-plilongigita) kaj funkciiganta kiel 32-bitaj entjeroj, la sama kielinttipoj.
La pli malgrandaj tipoj nur havas kelkajn tip-specifajn instrukciojn por ŝarĝado, stokante, kaj tipkonverton.booleanestas ne konata entute al la JVM;
bu-sonoblikvecoj estas funkciigis sur kiel 8-bitebytevaloroj, kun 0 reprezentadofalsekaj 1 reprezentadotrue.
#000017
La JVM havas rub-trankvilan stakon por stokado de objektoj kaj aroj.
Kodo, konstantoj, kaj aliaj klasdatenoj estas stokitaj en la "metodareo".
La metodareo estas logike parto de la stako, sed efektivigoj povas trakti la metodareon aparte de la stako, kaj ekzemple povo ne rubon kolekti ĝin.
Ĉiu JVM-fadeno ankaŭ havas it propran vokstakon (nomitan "Java Virtual Machine stack" por klareco), kiu stokas kadrojn.
Nova kadro estas kreita ĉiun fojon kiam metodo estas nomita, kaj la kadro kiam estas detruita tiuj metodelirejoj.
#000018
Ĉiu kadro disponigas "operaciantostakon" kaj aron de "lokaj variabloj".
La operaciantostako estas uzita por operaciantoj al komputadoj kaj por ricevado de la revenvaloro de nomita metodo, dum lokaj variabloj helpas la saman al kiel registroj kaj ankaŭ kutimas pasigi metodargumentojn.
Tiel, la JVM estas kaj stakmaŝino kaj registromaŝino.
#000019
La JVM havas instrukciojn por la sekvaj grupoj de taskoj:
#000020
Ĉiu speciala mastro operaciumo bezonas sian propran efektivigon de la JVM kaj rultempon.
Tiuj JVMoj interpretas la Bajtkodon semantike laŭ la saman manieron, sed la fakta efektivigo povas esti malsama.
Pli da komplekso ol ĵus kopiado Bajtkodo estas kongrue kaj efike efektiviganta la Java kernon Api kiu devas esti mapita al ĉiu mastro-operaciumo.
#000021
Tiu instrukciaĵo operacias aktoraro de komunpaŝtejo distritaj datenoj tajpas prefere la indiĝenajn datentipojn de iu specifa instrukciseriarkitekturo.
#000022
JVM-lingvo estas ajna lingvo kun funkcieco kiu povas esti esprimita laŭ valida klasdosiero kiu povas esti gastigita fare de la Java Virtuala Maŝino.
Klasdosiero enhavas Java Virtual Machine-instrukciaĵon ( Java bajtkodo) kaj simboltablon, same kiel aliajn flankinformojn.
La klasa dosierformato estas la hardvaro- kaj operaciumo-sendependa binara formato kutimis reprezenti kompilitajn klasojn kaj interfacojn.
#000023
Ekzistas pluraj JVM-lingvoj, ambaŭ aĝaj lingvoj adaptis al JVM kaj tute novajn lingvojn.
JRuby kaj Jython eble estas la plej bonkonataj havenoj de ekzistantaj lingvoj, t.e. Ruby kaj Python respektive.
De la novaj lingvoj kiuj estis kreitaj de komence por kompili al Java Bajtkodo, Clojure, Apache Groovy, Scala kaj Kotlin povas esti la plej popularaj tiajn.
Rimarkinda trajto kun la JVM-lingvoj estas ke ili estas kongruaj kun unu la alian, tiel ke, ekzemple, Scala bibliotekoj povas esti uzitaj kun Java programoj kaj inverse.
#000024
Baza filozofio de Java estas ke ĝi estas esence protektita de la starpunkto kiun neniu uzantoprogramo povas kraŝi la mastro-maŝinon aŭ alie influas malkonvene aliajn operaciojn sur la mastro-maŝino, kaj ke estas eble protekti certajn metodojn kaj datenstrukturojn apartenantajn al fidinda kodo de aliro aŭ korupto per nefidita kodefektivigo ene de la sama JVM.
Krome, oftaj programisteraroj kiuj ofte kondukis al datenkorupto aŭ neantaŭvidebla konduto kiel ekzemple alirado de la fino de aro aŭ uzado de neiniciigita montrilo ne estas permesitaj okazi.
Pluraj ecoj de Java kombinas por disponigi tiun sekurecon, inkluzive de la klasmodelo, la rub-trankvila stako, kaj la konfirmilon.
#000026
La JVM konfirmas ĉiun Bajtkodon antaŭ ol ĝi estas efektivigita.
Tiu konfirmo konsistas ĉefe el tri specoj de kontroloj:
#000027
Branĉoj ĉiam estas al validaj lokoj
Datenoj ĉiam estas initialigitaj kaj referencoj ĉiam estas tip-sekuraj
Aliro al malpubliko aŭ pakaĵo privataj datenoj kaj metodoj estas rigide kontrolitaj
#000028
La unuaj du el tiuj ĉekoj okazas ĉefe dum la konfirmpaŝo kiu okazas kiam klaso fariĝas ŝarĝita kaj elektebla por uzo.
La tria estas ĉefe farita dinamike, kiam datenobjektoj aŭ metodoj de klaso unue estas aliritaj fare de alia klaso.
#000029
La konfirmilo permesas nur kelkajn Bajtkodsekvencojn en validaj programoj, ekz. salto (branĉo) instrukcio povas nur celi instrukcion ene de la sama metodo.
Krome, la konfirmilo certigas ke ĉiu antaŭfiksita instrukcio funkciigas sur fiksa stakloko, [10] permesante al la JIT-kompililo transformi stakalirojn en fiksajn registralirojn.
Pro tio, ke la JVM estas stako arkitekturo ne implicas rapidecpunon por kopiado pri registro-bazitaj arkitekturoj dum uzado de JIT-kompililo.
Spite al la kod-konfirmita JVM-arkitekturo, ĝi faras neniun diferencon al JIT-kompililo ĉu ĝi estas nomita imagaj registroj aŭ imagaj stakpozicioj kiuj devas esti asignitaj al la registroj de la celarkitekturo.
Fakte, kodkonfirmo igas la JVM diferenca de klasika stakarkitekturo, de kiu efika kopiado per JIT-kompililo estas pli d komplika kaj tipe aranĝita fare de pli malrapida interpretisto.
#000030
La origina specifo por la Bajtkodkonfirmilo uzis naturan lingvon kiu estis nekompleta aŭ malĝusta en kelkaj rilatoj.
Kelkaj provoj estis faritaj por precizigi la JVM kiel formala sistemo.
Farante tion, la sekureco de aktualaj JVM-efektivigoj povas pli plene esti analizita, kaj ebla sekureco ekspluatas preventita.
Ankaŭ estos eble optimumigi la JVM transsaltante nenecesajn sekurecokontrolojn, se la aplikiĝo estanta prizorgita estas pruvita esti sekura.
#000031
Virtuala maŝinarkitekturo permesas tre fajngrajnan kontrolon de la agoj kiujn tiu kodo ene de la maŝino estas lica preni.
Ĝi supozas ke la kodo estas "semantike" ĝusta, t.e., ĝi sukcese pasigis la (formalan) Bajtkodan konfirmilprocezon, realigitan per ilo, eventuale ekster-estraro la virtuala maŝino.
Tio estas dizajnita por permesi sekuran plenumon de nefidita kodo de malproksimaj fontoj, modelo utiligita per Java apletoj, kaj alia sekura kodo elŝutas.
Post kiam bytecode-konfirmite, la elŝutita kodo kuras en limigita " sablokesto ", kiu estas dizajnita por protekti la uzanton de konstrua aŭ malica kodo.
Kiel aldono al la Bajtkoda konfirmprocezo, eldonistoj povas aĉeti atestilon kun kiu ciferece subskribi apletojn kiel monŝrankoj, donante al ili permeson peti al la uzanto krevi el la sablokesto kaj aliro la lokan dosiersistemon, tondejon, ekzekutas eksterajn pecojn de softvaro, aŭ reton.
#000032
Bajtkoda interpretilo kaj ekzakte ĝustatempa kompililo
#000034
Por ĉiu hardvararkitekturo malsama Java bajtkoda interpretilo estas necesa.
Kiam komputilo havas Java bajtkodan interpretilon, ĝi povas prizorgi ajnan Java Bajtkodprogramon, kaj la sama programo povas esti prizorgita sur iun komputilon kiu havas tia interpretiston.
#000035
Kiam Java Bajtkodo estas efektivigita fare de interpretisto, la ekzekuto ĉiam estos pli malrapida ol la plenumo de la sama programo kompilis en indiĝenan maŝinlingvon.
Tiu problemo estas mildigita de ekzakte ĝustatempaj (JIT) kompililoj por efektivigado de Java Bajtkodo.
JIT-kompililo povas traduki Java Bajtkodon en indiĝenan maŝinlingvon ruligante la programon.
La tradukitaj partoj de la programo tiam povas esti efektivigitaj multe pli rapide ol ili povus esti interpretitaj.
Tiu tekniko estas aplikita al tiuj partoj de programo ofte efektivigis.
Tiun manieron JIT-kompililo povas signife akceli la totalan ekzekuttempon.
#000036
Ekzistas neniu necesa ligo inter la java kaj Java Bajtkodo.
Programo skribita en Java povas esti kompilita rekte en la maŝinlingvon de reala komputilo kaj programas skribite en aliaj lingvoj ol Java povas esti kompilita en Java Bajtkodon.
#000037
Java Bajtkodo estas celita esti platformo-sendependa kaj certigi.
Kelkaj JVM-efektivigoj ne inkludas interpretiston, sed konsistas nur el ekzakte ĝustatempa kompililo.
#000038
Ekde la tre fruaj stadioj de la dezajnprocezo, Java (kaj JVM) estis surmerkatigita kiel interretteknologio por kreado de Rich Internet Applications.
#000039
Sur la klientoflankon, tTT-legiloj povas esti etenditaj kun NPAPI Java aldonaĵo kiu efektivigas tiel nomis Java apletojn integriĝintaj en HTML-paĝojn.
La apleto estas permesita uzi en rektangulan regionon la paĝon asignitan al ĝi kaj uzo limigitan aron de APIoj kiuj permesas ekzemple aliron al la mikrofono de uzanto aŭ 3D akceladon.
Adobe Flash Player, la ĉefa konkuranta teknologio, laboras en laŭ la saman manieron en tiu rilato.
Java kiun apletoj ne estas limigitaj al Javo kaj ĝenerale povas esti kreita en iu JVM-lingvo.
#000040
En junio 2015 [ĝisdatigo] laŭ W3Teks, Java apletuzo falis al 0.1% de ĉiuj retejoj.
Fulmo falis al 10.8% kaj Silverlight al 0.1% de retejoj.
#000042
JavaPoly permesas al retejoj uzi kontrolitajn nemodifitajn Java bibliotekojn, eĉ se la uzanto ne havas Java instalita sur ilia komputilo.
#000043
Kompilante la JVM-Bajtkodon, kiu estas universala en tuta JVM-lingvoj, permesas konstrui sur la ekzistanta kompililo de la lingvo al Bajtkodo.
#000044
Java Runtime Environment de Oracle
#000045
Al akcelada kodekzekuto, Retpunkto dependas de ekzakte ĝustatempa kompilo.
Al akceladobjektasigno kaj rubkolekto, Retpunkto uzas generacian stakon.
#000048
La Java virtuala maŝinstako estas la areo de memoro utiligita fare de la JVM por dinamika memorasigno.
#000049
En Retpunkto la stako estas dividita en generaciojn:
#000050
La junulgeneracio stokas mallongdaŭrajn objektojn kiuj estas kreitaj kaj tuj rubo kolektis.
Objektoj kiuj daŭras pli longe estas proponitaj al la malnova generacio (ankaŭ anoncis la permanentofican generacion).
Tiu memoro estas subdividita en (du) pluvivantospacojn kie la objektoj kiuj postvivis la unua kaj venontaj rubkolektoj estas stokitaj.
#000051
La permanenta generacio (aŭ ondumadinformo) estis uzita por klas difinoj kaj rilataj metadatenoj antaŭ Java 8-a Ondumaĵgeneracio ne estis parto de la stako.
La permanenta generacio estis forigita de Java 8.
#000052
Origine ekzistis neniu permanenta generacio, kaj objektoj kaj klasoj estis stokitaj kune en la sama areo.
Sed ĉar klasmalŝarĝado multe pli malofte ol objektoj estas trankvilaj okazas, movi klasstrukturojn al specifa areo permesis signifajn spektakloplibonigojn.
#000053
JRE de orakolo estas instalita sur granda nombro da komputiloj.
Ekde iu reto paĝigas la uzantvizitojn povas prizorgi Java apletojn, Java disponigas facile alireblan ataksurfacon al malicaj retejoj kiujn la uzanto vizitas.
Kaspersky-Laboratorioj raportas ke la Java tTT-legilaldonaĵo estas la metodo de elekto por komputilkrimuloj.
Java kiun atingoj estas inkluditaj en multaj ekspluatas pakojn kiujn retpiratoj deplojas sur hakitaj retejoj.
#000054
En la pasinteco, finuzantoj ofte uzis malmodernan version de JRE kiu estis minacata per multaj konataj atakoj.
Tio kondukis al la vaste komuna kredo inter uzantoj ke Java estas esence nesekura.
Ekde Java 1.7, JRE de Oracle por Fenestroj inkludas aŭtomatan ĝisdatigfunkciecon.
#000055
Klarigoj kaj Amendoj al la Java Virtual Machine Specification, Dua Eldono inkludas liston de ŝanĝoj por esti faritaj por apogi J2SE 5.0 kaj JSR 45
JSR 45, precizigas ŝanĝojn al la klasa dosierformato al subteno-font-nivela senararigado de lingvoj kiel ekzemple JSP (JSP) kaj SQLJ kiuj estas tradukitaj al Javo
#000058
Ordinara Evoluo kaj Distribution License
#000061