Masini VirtualeProiect Sisteme de Operare

Studenti: Grupa:

Horsa Alexandru 432ATodicescu Alexandru 432AToma Crina 432AUta Cosmin 432AZabava Dragos 431A

Masini Virtuale

Cuprins

Introducere (Toma Crina)......................................................................................................................3

Interpretarea de baza (Uta Cosmin)......................................................................................................4

Interpretarea binara...........................................................................................................................6

Masina virtuala la nivel de proces (Zabava Dragos).............................................................................8

Implementarea Mașinii Virtuale.........................................................................................................9

Arhitectura Masinilor Virtuale bazate pe limbaje de nivel inalt (Horsa Alexandru)..........................12

Masina virtuala Pascal P-Code..........................................................................................................13

Arhitectura memoriei.......................................................................................................................13

Masini virtuale bazate pe limbaje orientate pe obiecte...................................................................14

Arhitectura masinii virtuale Java......................................................................................................15

Formatul instructiunilor....................................................................................................................15

Interfata nativa Java.........................................................................................................................16

SISTEME DE MASINI VIRTUALE (Todicescu Alexandru).......................................................................17

VM NATIV VS VM HOSTAT................................................................................................................19

Virtualizarea resurselor....................................................................................................................20

Procesorul........................................................................................................................................20

Memoria...........................................................................................................................................21

Concluzii...........................................................................................................................................22

Bibliografie...........................................................................................................................................23

2

Masini Virtuale

Introducere(Toma Crina 432A)

Masina virtuala este un calculator imaginar, dotat cu un set de instructiuni ce constituie limbajul (codul) virtual.

Lucrul cu cod virtual decurge astfel: textul sursa este tradus de catre compilator in limbaj virtual; programul rezultat constituie intrare pentru o procedura numita executiv, care este de fapt un interpreter al limbajului virtual. Executivul este scris intr-un limbaj recunoscut de calculatorul tinta (cel pe care urmeaza sa ruleze programul compilat). Rolul executivului este acela de a parcurge codul virtual obtinut de la compilator si de a executa fiecare instructiune, in termenii limbajului masina al calculatorului tinta .

Avantajul acestui mod de lucru este acela ca daca un limbaj sursa trebuie tradus in mai multe limbaje obiect, compilatorul propriu-zis se scrie o singura data (el genereaza doar cod virtual), iar pentru fiecare limbaj obiect se construieste cate un executiv. A scrie un executiv este un lucru mult mai usor decat a scrie un compilator. Pe de alta parte, programul generat in cod virtual poate fi transportat pe orice masina dotata cu interpreterul codului respectiv, deci programul are o portabilitate crescuta.

Compilatoarele de Java, spre exemplu, genereaza cod virtual (numit byte-code). Astfel, un applet, care este de fapt un program Java compilat poate fi incarcat si executat de catre un browser de web dotat cu interpreter de byte-code, chiar in conditiile in care applet-ul si browser-ul se afla pe calculatoare care functioneaza sub sisteme de operare diferite. Un dezavantaj al lucrului cu cod virtual este acela ca viteza de executie a programelor respective este mai mica, deoarece ele sunt executate "software" (prin intermediul interpreterului) si nu "hardware" (direct de catre procesor).

Limbajul virtual si structura masinii virtuale sunt stabilite in principiu de catre proiectantul compilatorului, dupa urmatoarele criterii:

comenzile virtuale sa fie suficiente pentru a permite transpunerea corecta a instructiunilor limbajului sursa;

functionarea masinii virtuale sa poata fi cat mai usor de simulat cu ajutorul executivelor, pentru fiecare limbaj obiect.

In general, limbajul virtual este inspirat din limbajele de asamblare existente la un moment dat, avand insa un grad ceva mai mare de abstractizare.

3

Masini Virtuale

Maşinile virtuale sunt folosite în principal pentru:

multiplicarea maşinilor existente. Serverele, de obicei, rulează la niveluri joase ale capabilităţilor pe care le au. Din cauza acestui fapt se pot instala maşini virtuale ce pot satisface acelaşi cerinţe ale utilizatorului ca şi serverul gazdă. Acest lucru reprezintă o economie importantă de bani.

testarea de aplicaţiei ce urmeaza a fi lansată pe alte platforme. Lansaţi o aplicaţie ce ruleaza pe Linux dar distribuţia în care lucraţi este Fedora şi doriţi să testaţi pe o alta. Este foarte simplu creerea unei maşini virtuale ce rulează distribuţia dorită.

rularea unui anume tip de cod maşină. Exemplul cel mai elocvent este Java Virtual Machine ce permite rularea de aplicaţii scrise în limbajul Java pe multe platforme.

Interpretarea de baza(Uta Cosmin 432A)

Interpretarea are o istorie îndelungată şi bogată. Unele limbaje de programare, de exemplu, limba funcţionale LISP, se bazează pe o implementare interpretata. Perl este un limbaj utilizat pe scară largă , care este frecvent pus în aplicare prin intermediul interpretarii.Limbajul FORTH este, probabil, mai bine cunoscuta pentru „threaded code”" fiind interpretareamodel pentru orice altă caracteristică. Un bun punct de referinţă este si DebaereVan Campenhout (1990). În acest capitol, însă, suntem mai interesaţi deaplicarea tehnicilor de interpretare a programului binar (cod masina), mai degrabădecât limbajele de nivel înalt.

Un exemplu de cod de interpretare a instructiunii de PowerPc este :

LoadWo rdAndZe ro ( inst) {

RT = extract(inst,25,5) ;RA = extract(inst,20,5);displacement = extract(inst,15,16);if (RA == O) source = O;else source = regs[RA];address = source + displacement;

4

Masini Virtuale

regs[RT] = (data[address]<< 32) >> 32;PC = PC + 4;

}

ALU(inst){

RT = extract(inst,25,5);RA = extract(inst,20,5) ;RB = extract(inst,15,5);source1 = regs[RA];source2 = regs[RB];extended_opcode = extract(i nst, 10,10) ;switch (extended_opcode) {case Add: Add(inst);case AddCarrying: AddCarrying(inst);case AddExtended: AddExtended(inst);}

PC = PC + 4;

}

Desi e simplu de scris si de interpretat , o interpretare decodata poate fi inceata.Principala bucla dintr-o interpretare decodata contine o serie de ramuri de instrunctiuni atat indirecte cat si directe. In funcţie de implementarea hardware, aceste ramuri au tendinţa de a reduce performanţele mai ales dacă acestea sunt dificil de prezis.Exista un registru indirect pentru ramura schimbarii starii, o ramura catre interpretorul de rutina , un al doilea registru indirect care returneaza interpretorul de rutina si in final o ramura care termina bucla.

O proprietate cheie a interpretarii „thread” este aceea ca expediera are loc indirect printr-un tabel.Ca o parte a avantajelor acestui lucru, este faptul ca rutina interpretarii poate fii modificata si mutata independent.Deoarece saltul prin acest tabel este indirect, aceasta metoda este numita „indirect threaded interpretation”.

Predecodarea implica schimbarea unei instructiuni si punerea acesteia intr-o forma care simplifica interpretarea.In particular,predecodarea extrage parti din informatie si le pune in campuri mai usor de accesat sau o poate combina intr-un cod al unei operatii.De asemenea, registrii specifici pot fi extrasi din sursa binara si pusi in campurile „byte-aligned” pentru a fii accesati direct cu instructiuni de incarcare a octetilor.

Un exemplu de cod direct de interptretare „thread” este :5

Masini Virtuale

Load Word and Zero:

RT = code [TPC]. dest ;RA = code [TPC]. s rcl;displacement = code[TPC] .src2;if (RA == 0) source = 0;else source = regs[RA] ;address = source + displacement;regs[RT] = (data[address]<< 32) >> 32;SPC = SPC + 4;TPC = TPC + 1;I f ( h a l t I I interrupt) goto exit;routi ne = code [TPC]. op;goto * routine

Interpretarea binaraCu ajutorul predecodarii, toate instructiuniile sursa de acelasi tip sunt executate cu acelasi interpretare de rutina.Performanta poate fi imbunatatita intr-un mod semnificativ prin maparea fiecarei surse prin interpretare binara cu un propriu cod personalizat. Acest proces de conversie a programului sursă într-un program binar se numeste interpretarea binara.

Un exemplu de interpretare binara este :

rl points to IA-32 register context blockr2 points to IA-32 memory imager3 contains IA-32 ISA PC valuer4 holds IA-32 register %eaxr7 holds IA-32 register %edxaddi r16, r4,4 ;add 4 to %eaxlwzx r17, r2, r16 ;load operand from memoryadd r7,r17,r7 ;perform add of %edxaddi r16, r4,4 ;add 4 to %eaxstwx r7, r2, r16 ;store %edx value into memoryaddi r4,r4,4 ; increment %eaxaddi r3, r3,9 ;update PC (9 bytes)

Unele dintre registrele tinta sunt mapate direct catre unele dintre registrele sursa astfel valorile sursei sunt mentinute in registrele tinta.Alte portiuni ale sursei , cum ar fii contorul de program si stiva, pot fi tinute in

6

Masini Virtuale

registrele tinta.Dupa ce se face maparea, unele registre tinta ar trebuii lasate peste pentru utilizare codului emulator.

Codul tradus este accesat de un program tinta (TPC) care este diferit programul tinta al sursei (SPC).De aceea se creaza o problema cand exista un control de transfer indirect in codul sursa.Adresa destinatiei codului de transfer este tinuta intr-un registru si este o adesa cod a sursei.Dupa emulare trebuie sa exista o cale de mapare de la adresa SPC la adresa TPC.

Codul „discovery” este o problema atat pentru predecodare cat si pentru interpretarea binara.In ambele cazuri, o solutie generala este sa traducem binarul in timp ce programul ruleaza pe o data actuala dinamica, si sa predecodam sau sa traducem noi sectiuni al codului incrementat atunci cand programul ajunge la ele.Deoarece acest proces este asemanator pentru amadoua, ne referim la el ca o interpretare.

In timp ce blocurile de cod sunt traduse ,ele sunt punse intr-o regiune regiune special conceputa pentru ele.Cu cat mai multe blocuri sunt traduse, regiunea de memorie poate devenii foarte mare.Pentru a reduce zona de memoria unde este salvata traducerea, aceasta este organizata intr-un cod cache.Obiectivul acestui cod este sa retina cele mai recente blocuri de cod traduse.

Sistemul traduce un bloc al codului sursa la un moment de timp.Intr-o simpla schema de traducere,modul natural de traducere este „dynamic basic block”.Acesta este diferit de blocurile de baza conventionale,determinate de structura statica a programului.Un bloc static de instrunctiuni contine o secventa cu o singura intrare si o singura iesire.

Un bloc dinamic este determinat de debitul programului care este executat.El incepe mereu cu instructiunea executata imediad dupa salt.Acesta continua pana cand prima conditiei a ramurei este intalnita.Blocurile dinamice tind sa fie mai mare decat cele statice.

7

Masini Virtuale

Masina virtuala la nivel de proces(Zabava Dragos 431A)

Un utilizator de computer  tipic  funcţionează  cu un număr mare de  programe  care coexistă într-un mediu de sistem compus din una sau mai multe  procesoare, memorie, un sistem de fişiere, şi un număr de dispozitive periferice.

8

Masini Virtuale

Utilizatorul invocă şi interacţionează cu programele prin interfata  susţinută  de  biblioteci şi sistemul de operare. O restricţie importantă, însă, este faptul că utilizatorul  poate rula numai programele care au  fost compilate pentru sistemul de operare al utilizatorului şi setul de instrucţiuni ale procesorului . Una din aplicaţiile  importante ale mașinii virtuale este de a eluda această restricţie şi a permite utilizatorului să ruleze programe compilate pentru alte sisteme. Aşa cum  vom vedea, un număr mare de arhitecturi de tip VM (masina virtuala) pot oferi această  capacitate, dar cea mai simplă  abordare a VM ,din perspectiva utilizatorului, este de program oaspete dezvoltat pentru un alt computer decât sistemul  gazdă al utilizatorului poate fi instalat şi utilizat în acelaşi mod ca şi toate celelalte programe de pe sistemul gazdă; utilizatorul, precum şi alte programe interacţionează cu  programul oaspete în acelaşi mod în care interacţionează cu programe gazdă native.

Programele pentru calculator sunt compilate,distribuite, şi stocate ca fişiere binare executabile care sunt conforme cu o interfaţă de aplicatie binară,  sau ABI, care include caracteristici atăt ale setului de instrucţiuni hardware, cat şi ale  sistemului de operare. De exemplu, un ABI utilizat pe scară largă este cel proiectat pentru a executa pe un procesor de ce suporta Intel IA-32 ISA şi sistemul de oparare Microsoft Windows. Acum câţiva ani, Intel a dezvoltat un nou procesor ISA , pe 64 de biţi, numit acum IPF, care este implementat în familia deprocesoare Itanium. Programele de tip aplicație pe IA-32 nu vor rula direct de pe platformele Itanium, chiar dacă sistemul de operare Windows a fost portat pentru platformele Itanium.  Deci, pentru a permite utilizatorilor să ruleze numărul mare de aplicaţii IA-32/

9

Masini Virtuale

Windows pe platforme Itanium, cei de la Intel a dezvoltat un mediu virtual IA-32/ Windows. Procesul de VM rezult, IA-32 EL (strat de executie-execution layer), permite programelor IA-32 să apară unui utilizator Itanium exact aşa cum ar aparea pe o platforma IA-32 nativa.  O altă versiune a procesului de IA-32 EL VM cu o altă intrfață de sistem de operare este cea care suporta aplicatii IA-32/Linux.

Fig 1. A Guest Process, with Process VM Support in the Form of Runtime Software, Interacting with Host Processes.

Figura 1. ilustrează un mediu tipic de maşină virtuală de tip proces. Cum se vede și în figură, software-ul runtime încapsulează, în esenţă, un proces oaspete individual, oferindu-i acelaşi aspect exterior ca un proces nativ gazdă. Din punctul de vedere al procesului oaspete, toate celelalte procese par să conforme cu viziunea  sa. Prin urmare, procesul oaspete poate interacţiona cu procesele gazdă native în  acelaşi mod in care procesele gazdă interacţionează intre ele. În plus, procesele oaspete pot interacţiona cu alte procese oaspete ca şi cum acestea ar fi rulat pe o maşină reală.

Implementarea Ma inii Virtualeș

Blocurile majore de calcul si structuri de date ale unei VM de tip proces  sunt afişate în Figura 2.

10

Masini Virtuale

Fig 2. Implementation of a Process Virtual Machine.

Blocurile majore efectueaza următoarele funcţii:

Încărcătorul (the loader) scrie codul oaspete şi de date într-o regiune de memorie reținând imaginea memoriei oaspete şi încarcă codul runtime. Deşi imaginea memoriei conţine codul aplicație oaspete, precum şi date, din punct de vedere al runtime sunt toate date,deoarece codul  sursă nu este direct executat.Mai degrabă, codul sursă este folosită ca input "date " pentru interpretarea şi / sau a rutinelor de traducere binară.

Încărcătorul ofera apoi controlul blocului de iniţializare(initialization block), care alocă spaţiu de memorie pentru codul cache şi alte tabele utilizate în timpul procesului de emulare. Procesul de iniţializare invocă, de asemenea, sistemul de operare gazdă pentru a stabili semnalele de taratare pentru toate condiţiile capcana care pot apărea (cel puţin cele pentru care semnalele sunt suporate de sistemul de operare). După iniţializare, procesul de emulare(emulation) poate  începe,  de obicei folosind o serie tehnici de emulaţie într-o manieră eşalonată.

Emulatorul folosește interpretarea şi / sau traducerea binară  pentru a emula instrucţiunile clienţilor.Dacă traducerea binară este  folosită ca o metodă de emulare, codul țintă tradus este ţinut într-un cod cache. Codul cache,care este scris de către traducător,este o zonă de cod executabil în timp desfășurării emulării. Dacă emularease efectuează prin interpretarea cu o formă intermediară  predecodată, instrucţiunile predecodate sunt stocate într-o structură similară cache.

Din cauza dimensiunii limitate a codului cache, managerul  codului cache este responsabil pentru a decide care dintre traduceri ar trebui să fie eliminate din cache pentru a face loc pentru noi traduceri care urmează să fie generate.

11

Masini Virtuale

bază de date de profil (profile database) conţine informaţii despre program, dinamic colectate, care sunt folosite pentru a ghida optimizarea în timpul procesului de traducere.

În timp ce emularea are loc şi programul oaspete efectuează un apel de sistem, Emulatorul de apel catre SO (OS call emulator) traduce  apelul către sistemul de operare într-un  apel adecvat (sau apeluri) la sistemul de operare şi apoi se ocupă de orice informaţie asociată întoarsă ca urmare a apelului.

Runtime trebuie să se ocupe, de asemenea, de capcanele care pot apărea ca urmare a executării fie a unei instrucţiuni de interpretare sau a unei instrucţiune traduse, şi trebuie să se ocupe de orice intreruperi care sunt  îndreptate la procesul oaspete. Runtime face acest lucru cu emulatorul de exceptii(exception emulator). În unele cazuri, emulatorul de excepții intră în acțiune atunci când o capcana de emulare declanşată cauzează semnalul către sistemul de operare să fie livrat la runtime; în alte cazuri, rutinele de emulare descopera o condiţie de excepţie şi sare către emulatorul de excepții . Un aspect important al tratării exceptiilor de runtime este generarea unei stări de oaspete corecte, precise (inclusiv numărătorul de program,  valorile regiștrilor, şi condiţiile de capcana) atunci când apare o condiţie excepţie.

Tabele adverse( side tables), de exemplu, structurile de date generate ca parte a procesului de traducere, sunt utilizate de runtime, ca parte a procesului de emulaţie global. O utilizare importantă de tabele adverse este este în implementarea un model precis de excepţii cu privire la sursa de ISA.

Instrucțiunile de emulare se poat face prin (1)interpretare, (2) traducere binară, sau (3) o combinaţie pusă în scenă. Maparea adreselor şi protecţia memoriei poate fi făcută : (1) prin intermediul unui tabel manageriat de runtime sau (2) folosind maparea directă.  Opţiunile cele mai potrivite pentru o implementare dată depinde de  performanţă, complexitate, şi de compatibilitate schimburilor (tradeoff).

Metoda cea mai generală de aplicare a emulației este folosirea interpretării de instrucțiuni cu maparea software a memoriei şi verificarea protecţiei. Această

12

Masini Virtuale

metodă adăposteşte compatibilitate intrinsecă,dar ar fi probabil cea mai lentă metodă de emulare. Pe de altă parte, în cazul în care (1) Starea regiștrilor a clienţilor se încadrează în fișierul de regiștrii gazdă,  (2) spaţiu de memorie oaspete încape în spațiul gazdă,  (3),  dimensiunea  paginii oaspeţilor este un multiplu al dimensiunii  paginii  gazdă, şi (4) tipurile de privilegiu ale oaspeților sunt un subset al nivelurilor de privilegii ale gazdei, apoi, în general, traducerea binară cu  maparea hardware a adreselor şi verificarea sunt probabil cea mai rapidă metodă de emulare, şi  de asemenea, este foarte probabil ca o compatibilitate intrinsecă sa fi atinsă.

Condiţiile de mai sus par, inițial, să fie destul de restrictive;cu toate acestea, unele cazuri practice importante îndeplinesc  aceste constrângeri. Unul dintre cazurile practice importante este de virtualizare de IA-32  ABI pe o platformă RISC(sau un IPF Intel / platformă Itanium). În acest caz, de exemplu, IA-32 fişier de registrii de obicei, se potriveşte confortabil în interiorul fişier de registrii gazdă, şi spațiul de adrese al 32-bit IA-32 se potriveşte într-un spaţiu tipic de adrese pe 64 de biţi.

În multe alte situaţii, mașinile virtuale de tip proces pot fi construite pentru a satisface constrângeri de compatibilitate extrinseci. Acestea oferă  doar  compatibilitate pentru unii clienți binari, dar nu pentru toți. Compromisul cel mai important care trebuie să se producă are loc atunci când gazda şi oaspetele suportă sisteme de operare diferite. În acest caz, emulare a SO oaspete este probabil să fie incompletă. Acest lucru ar limita aplicațiile la cele care depind de un subset de apeluri de sistem sau de un subset de caracteristici ale SO.Indiferent de ce compatibilitate este satisfacută ar trebui verificată pe program de baza echivalent, după toate probabilităţile.

Ce face ca masinile virtuale de tip proces sa iasă în evidență este punctul dela care apelurile către sistemul de operare sunt interceptate şi emulaţia  se efectuează ~ pentru o mașină virtuală de tip proces acest punct se află la interfaţa utilizatorului cu sistemul de operare.

Arhitectura Masinilor Virtuale bazate pe limbaje de nivel inalt(Horsa Alexandru 432A)

13

Masini Virtuale

In mod conventional, o aplicatie compilata este strans legata de sistemul de operare si de un set de instructiuni. Pentru executarea aplicatiei pe o platforma cu un sistem de operare diferit si/sau alt set de instructiuni, este nevoie de recompilarea acestuia. Uneori, acest lucru implica rescrierea anumitor librarii sau translatarea unor apeluri de sistem.

Pe langa portabilitate, setul de instructiuni al sistemului de operare virtual poate fi construit astfel incat sa reflecte trasaturile specifice unui limbaj de nivel inalt. Astfel, pot fi implementate eficient limbajele de nivel inalt, simplificand procesul de compilare prin separarea compilatorului in portiuni dependente de sistem si independente de sistem. Deoarece, unul din scopurile acestor masini virtuale este suportul eficient al limbajele de nivel inalt, sunt denumite si high-level language virtual machines(HLL VMs).

O masina virtuala construita pe baza caracteristicilor limbajelor inalte (HLL VMs) este similara unei masini virtuale bazata pe procese, dar in general, setul de instructiuni este definit pentru programele ce ruleaza in modul utilizator. Prin urmare, pot fi executate numai pe un procesor virtual. In consecinta, denumirea lor este seturi de instructiuni virtuale (V-ISA). Interfata sistemului consta dintr-un set de librarii standard care pot, spre exemplu, sa acceseze fisiere, sa comunice in retea si sa execute operatii grafice. Teoretic, masinile virtuale sunt concepute sa suporte toate sistemele de operare, dar practic, trebuie sa le suporte macar pe cele mai uzuale.

Se poate vizualiza masina virtuala din perspectiva limbajului/compilatorului in figura de mai sus. Pasii pentru trecerea unui

14

Masini Virtuale

program de la limbajul de nivel inalt la cod masina, se observa in figura (a). Compilatorul parseaza programul si il converteste intr-o forma intermediara. Aceasta forma este preluata, optimizata, in unele cazuri, iar apoi este generat codul obiect de catre compilator. Codul obiect este asemanator cu formatul seturilor de instructiuni, in afara unor informatii simbolice, care sunt rezolvate in momentul incarcarii. In final, codul obiect este convertit la o imagine de memorie, executata de procesorul hardware. In general, programul este distribuit sub forma codului obiect, si poate fi rulat doar pe platformele compatibile cu sistemul de operare si setul de instructiuni pe care a fost compilat. In cazul unei masini virtuale, figura (b), compilatorul parseaza si converteste programul intr-un set de instructiuni virtual, asemanator cu forma intermediara conventionala. Programul este distribuit in aceasta forma. In momentul executiei, este convertit intr-o forma dependenta de implementarea masinii virtuale. Optimizarile pot avea loc in procesul de emulare, ce presupune interpretarea si/sau translatarea binara de la sistemul virtual la sistemul gazda. Cele mai importante componente ale implementarii masinii virtuale sunt interpretorul/translatorul si componenta care se ocupa de incarcarea programelor.

Un exemplu bine cunoscut de masina virtuala bazata pe limbajul de nivel inalt a fost proiectata sa suporte limbajul Java. Programele Java sunt compilate in prima faza in clase Java binare, care contin multe instructiuni codificate sub forma de secvente „bytecode” si „metadate”. Masina virtuala Java (JVM) incarca apoi clasele binare si le executa. O alta masina virtuala, mai recenta, CLI (common language infrastructure), face parte din cadrul Microsoft .NET.

Masina virtuala Pascal P-CodePopularitatea limbajului de nivel inalt Pascal, s-a datorat masinii

virtuale Pascal P-code, deoarece a simplificat portarea compilatorului. Compilatorul parseaza programul Pascal si genereaza codul-P, care reprezinta un set de instructiuni simplu, orientat spre expresiile de tip stiva. Combinatia dintre un compilator Pascal si masina virtuala P-code reprezinta un compilator Pascal complet si un sistem de executie pentru platforma gazda. Compilatorul este dezvoltat o singura data si distribuit sub forma P-code, si portarea catre o noua platforma se reduce la implementarea masinii virtuale. Acest procedeu este mult mai usor decat scrierea unui compilator Pascal complet, de la zero. Masina virtuala P-code are doua mari componente: emulatorul P-code, iar cea de-a doua este un set standard de librarii care comunica cu sistemul de operare gazda pentru a implementa operatiile de intrare/iesire.

15

Masini Virtuale

Arhitectura memorieiSetul de instructiuni virtual P-code foloseste un model de memorie

care consta dintr-o zona de memorie a programului, o zona constanta, o stiva si o zona de memorie „heap” pentru date. Un numarator de program aduce instructiunile din zona de program, altfel aceasta nu poate fi citita sau scrisa. Figura de mai jos ilustreaza zonele de date din memorie. Toate zonele de date sunt impartite in celule, iar fiecare celula poate retine o singura valoare. Dimensiunea unei celule depinde de implementare dar trebuie sa fie suficient de mare pentru a stoca cea mai mare valoare care poate fi specificata in codul-P. Compilatorul genereaza valorile din zona constanta. Acestea reprezinta in mod obisnuit, operanzii folositi de program. O singura stiva actioneaza ca stiva de proceduri, pentru a stoca informatiile de legaturi, parametrii si variabile locale, si ca stiva de evaluare a operanzilor pentru executarea instructiunilor.

Zona de memorie „heap” este deasupra zonei constante si stocheaza structurile alocate dinamic. Un nou pointer (NP) delimiteaza dimensiunea maxima a zonei „heap”. La apelul unei proceduri, se aloca un nou cadru in stiva. Stiva este impartita in mai multe sectiuni vizibile in figura de mai jos. Valoare returnata de functie, legatura statica si cea dinamica, si adresa de intoarcere reprezinta o regiune de dimensiune fixa la inceputul cadrului din stiva, denumita „mark stack”.

Masini virtuale bazate pe limbaje orientate pe obiecteUn program contine cod independent de platforma si „metadate”

dependente de sistem. „Meta datele” reprezinta structurile de date, in general obiectele, atributele si relatiile dintre ele. Dupa cum se observa in figura de mai jos, software-ul masinii virtuale este constituit dintr-un

16

Masini Virtuale

emulator care poate interpreta sau translata codul in cod nativ. Arhitectura masinii virtuale cuprinde, de asemenea, un modul de incarcare, ce converteste „meta datele” in structuri de date specifice masinii gazda.

In prezent cele mai promovate si utilizate masini virtuale (HLL VM) sunt „Java Virtual Machine (JVM)” si „Microsoft common language infrastructure (CLI)”. Masinile virtuale moderne se caracterizeaza prin diverse trasaturi sofisticate:

Securitate si protectie. Necesitatea securitatii apare, spre exemplu, la rularea programelor din surse care nu prezinta incredere, cum ar fi Internetul, fara a compromite securitatea sistemului local.

Robustete. Pentru dezvoltarea sistemelor software de scara larga, modelul programarii orientate pe obiecte se potriveste foarte bine cu calculul distribuit si legaturile dinamice.

Comunicarea in retea. Componentele hardware de retea au latimea de banda limitata, ceea ce favorizeaza programele care utilizeaza reteaua eficient. In consecinta, aplicatiile software trebuie incarcate pe bucati, la cerere, utilizand legaturi dinamice.

Performanta. In timp ce indeplineste toate caracteristicile de mai sus, se doreste si atingerea unei performante bune. In general, poate fi sacrificata o parte din performanta, dar o masina virtuala buna trebuie sa faca parte dintr-un cadru complet care sa ofere utilizatorului o buna performanta.

Arhitectura masinii virtuale JavaSetul de instructiuni

Java are un set de intructiuni de arhitectura orientat pe stiva, si poate fi asemanat cu setul de instructiuni utilizat de P-code.

Formatul instructiunilor

17

Masini Virtuale

Toate instructiunile contin un cod „opcode” si inca zero sau mai multi bytes. In figura de mai jos se observa diverse formate de instructiuni. Fiecare camp al instructiunii contine exact un byte, desi doua sau mai multe campuri pot fi concatenate pentru a forma un singur operand. Multe instructiuni au un singur byte, continand doar „opcode”-ul. In figurile (b) si (c) se observa instructiuni ce contin codul op si un index format dintr-unul sau doi bytes. Octetii de index sunt utilizati ca indici pentru plaja de constante sau pentru locatiile de stocare locala. O alta clasa de formate de instructiuni este reprezentata de un „opcode” si unul sau mai multi bytes de date, vizibile in figurile (d) si (e). Din cauza ca instructiunile sunt sub forma unor siruri de bytes sau „opcodes”, indici, sau date, un set de instructiuni mai este denumit in mod generic „bytecode”.

O proprietate de baza a setului de instructiuni Java este ca fiecare tip de primitiva are o instructiune „bytecode” specifica. Spre exemplu, „opcode”-ul „iadd” (adunare de intregi) poate fi folosit doar pentru operanzi intregi.

Interfata nativa Java„Java native interface” (JNI) ofera posibilitatea codului java si a

codului nativ compilat sa interopereze. De exemplu, codul java poate apela o rutina compilata in C, si invers. Prin utilizarea JNI, un program C are posibilitatea de a invoca o masina virtuala Java.

O vedere de ansamblu asupra JNI dar si asupra operatiilor sale se poate observa in figura de mai jos. In partea stanga a imaginii, se observa arhitectura Java. Codul si datele compilate pe o platforma nativa se afla in partea dreapta a imaginii. O observatie importanta este ca Java poate fi compilat din orice limbaj unde exista un compilator care poate produce clase binare standard, spre exemplu C#. Partea nativa poate fi compilata din C sau din orice alt limbaj pentru care exista suport JNI, inclusiv limbaj de asamblare. Fiecare parte din figura de mai jos se compileaza intr-un

18

Masini Virtuale

format binar propriu. Astfel, pentru java exista clasele binare standard, iar pentru partea nativa, programe binare in codul nativ al platformei respective. Datele, in partea Java, exista sub forma de obiecte si tablouri pe „heap” si variabile in stiva. In zona nativa, datele sunt organizate de catre compilator intr-un mod oarecare, cu alte cuvinte sunt dependente de compilator.

JNI ofera o interfata pentru metodele Java prin intermediul careia sa poata apela metode native. Pentru aceasta, metoda nativa trebuie declarata „native” de clasa Java apelanta. Dupa compilarea clasei Java in care este declarata metoda nativa ce va fi apelata, este utilizat programul „javah” pentru a genera un fisier header pentru metoda nativa.

Controlul aplicatiei poate fi transferat intre codul Java si metodele native prin intermediul interfetei native Java. Astfel pot fi transferate argumente si se pot returna valori. In ceea ce priveste exceptiile prinse si aruncate de codul nativ, pot fi tratate de catre aplicatia Java. Pentru a putea fi accesate datele din zona Java de catre codul din partea nativa, JNI ofera cateva metode native. Spre exemplu, „GetArrayLength” va intoarce dimensiunea unui tablou Java, iar GetIntArrayElements returneaza un pointer catre elementele unui tablou Java.

19

Masini Virtuale

SISTEME DE MASINI VIRTUALE(Alexandru Todicescu 432A)

S-a observant de ceva vreme că multe din resursele  hardware dintr-un calculator obisnuit sunt utilizate ineficient. Conceptul de time sharing a fost dezvoltat pentru a imbunatati utilizarea resurselor prin permiterea mai multor utilizatori sa acceseze un singur system in mod simultan, fiecare utilizator avand impresia de a avea acces la un set complet de resurse. Pentru a creea ilusia aceasta, un system de operare multiprogramat implementeaza un process de masina virtual pentru fiecare program al nivelului de aplicatie si comuta resursele intre programe folosind time sharing.

Sistemele de masini virtuale duc acest concept o etapa mai departe prin oferirea unei iluzii similar pentru sisteme complete. Un mediu de sistem VM(Virtual Machine) este capabil sa suporte mai multe imagini de sistem simultan., fiecare rulandu-si propiul sistem de operare si aplicatiile aferente. Fiecare sistem de operare controleaza un set de resurse hardware virtuale. Resursele virtuale alae unui procesor(sau procesoare), resursele de stocare si dispozitivele periferice trebuie sa efectueze I/O pentru sistem.

Intr-un mediu de sistem VM, resursele reale ale platformei gazda sunt impartite intre sistemele client(guest) prin software, utilizand VMM, monitorul masinii virtuale, care se ocupa de alocarea si accesul la resursele hardware ale platformei gazda. VMM detine reusrsele reale ale sistemului si le face accesibile pentru unul sau mai multe sisteme de operare client care sunt executate alternativ pe aceeasi platforma.

Fiecare resursa virtuala poate avea sau nu un corespondent in resursele fizice. Cand o resursa fizica este libera, VMM decide cum va fi dat accesul masinilor virtuale care au nevoie de ea. De exemplu, resursa poate fi partitionata sau poate fi impartita in timp (time shared). Cand o resursa virtuala nu are o resursa fizica corespondenta, VMM poate emula actiunea resursei dorite, in mod normal printr-o combinatie de software si alte resurse fizica care sunt libere pe platforma gazda.

Sistemele de masini virtuale au numeroase aplicatii, unele in trecut, altele cu relevanta in ziua de astazi si multe care probabil vor avea importanta in viitor. Cateva din aplicatii sunt:

Implementarea multiprogramarii:

20

Masini Virtuale

Medii sigure multiple Medii cu aplicatii administrate Medii cu diverse sisteme de operare Aplicatii legacy Dezvoltarea de aplicatii multiplatforma Dezvoltare de software de system Help Desk suport: Monitorizare de evenimente Encapsulare

Un aspect important este controlul resurselor. Intr-un mediu de sistem de VM, resurse hardware sunt asignate unei VM in momentul cand aceasta este creata, in functie de specificatiile de configuratie. Odaca ce resursele sunt data unui client VM, este important sa existe o metoda ca VMM sa le poata lua inapoi pentru a putea fi asignate unei alte VM. Astfel, VMM trebuie sa detine un control general al resurselor hardware, chiar daca acestea sunt temporar folosite de un client VM.

O problema asemanatoare apare in cazul sistemelor care folosesc time sharing conventional. Intr-un mediu de sistem de masina virtuala, principala problema este aceea a time sharingului resurselor de catre diferitele masini virtuale. Un mod convenabil de a furniza lui VMM un control general este ca VMM sa intercepteze toate accesele catre asa zisele resurse privilegiate, cum ar fi timerul de interval. Asadar aceste resurse privilegiate nu sunt folosite in mod direct de catre fiecare masina virtuala in parte, VMM emuleaza operatiile acestor resurse. In loc sa permita sistemului de operare dintr-o masina virtuala sa raspunda de timerul de intrerupere, VMM se ocupa intai de intreruperea in sine.

VM NATIV VS VM HOSTATVMM is the key component in any system

VMM este componenta cheie intr-un sistem de masina virtuala. VMM este responsabil pentru programarea si alocarea de resurse hardwarepentru masinile virtuale clienti. Astfel, este un punct de control pentru resursele fizice partajate. Aceste resurse include registrii din UCP,

21

Masini Virtuale

memoria reala a sistemului, asadar cel putin o parte a implementarii VMM ar trebui sa aiba privilegii mai ridicate decat privilegiile masinilor virtuale clienti pe cale le suporta.

Si stemul de operare lucreaza in general cu un privilegiu mai ridicat decat al celorlalte aplicatii(ex. Modul sistem vs modul user). Un sistem de masina virtuala in care VMM opereaza cu un privilegiu mai ridicat decat clientii VM se numeste un sistem VM nativ. Intru-un sistem VM nativ, VMM este singurul software care face executii in cel mai inalt privilegiu definit de arhitectura sistemului. VMM este primul instalat pe hardware iar sistemele de operare clienti sunt instalate peste VMM, ele avand privilegii mai scazute decat VMM.

Pentru convenienta utilizatorilor si simplitatea implementarii, este avantajos sa se instaleze un sistem de masina virtuala pe o platforma care are deja un sistem de operare instalat. Un asemenea sistem este numit sistem VM hostat. Intr-un sistem VM hostat VMM utilizeaza functii care sunt deja disponibile pe sistemul de operare gazda.

IBM VM/370

Primul mediu de masina virtuala a fost IBM System/360 Model 40 VM

(circa 1965) (Adair et al. 1966; Creasy 1981). Intentia dezvoltatorilor a fost sa construiasca un sistem bazat pe time sharing care sa axtinda conceptul nou aparut de atunci, memoria virtuala, spre alte parti ale sistemului de calculator. Dupa dezbaterea alternativelor, echipa de design a decis ca cel mai adecvat mod de a servi utilizatorul este arhitectura System/360(ISA) in loc de interfata oferita de functii date de librarii de sistem(ABI) . Avantajul era acela de a proteja utilizatorii unul de celalat, prezervand compatibilitatea odata cu evolutia arhitecturii lui System/360.

BMM al VM/370 se numea program de control (CP). Echipa de design al CP a dezvoltat un sistem de operare single-user numit conversational monitor system (CMS), in principiu pentru a demonstra avantajele modularizarii pentru evolutia sistemelor.

Designul CP/CMS a separat functia de management al resurselor de functia de functia de oferire de servicii catre user. Succesul proiectului s-a datorat in mare parte designului arhitecturii System/370, care permitea o

22

Masini Virtuale

implementare simpla a conceptului de VM. Chiar daca CP si CMS sunt adesea referite impreuna, cele doua nu pot exista fara cealalta. De fapt, CMS a fost dezvoltat inainte de CP, iar CP a hostat diverse sisteme de operare de-a lungul timpului, printre care, cel mai recent, Linux.

Virtualizarea resurselorProcesorul

Aspectul cheie al virtualizarii procesorului consta in executia instructiunilor cloentului, incluzand aici si instructiunile de la nivelul de sistem si cele de la nivelul user. Exista doua moduri in care aceasta se poate realiza. Prima metoda este prin emulare. Emularea se poate realiza fie prin interpretare, fie prin translatare binara. Emularea implica examinarea fiecarei instructiuni in parte, fie in mod repetat pentru metoda interpretarii fie o singura data pentru metoda translatarii binare. De asemenea, implica emularea pe resursele virtuale exact actiunile care ar fi fost realizate pe resurse reale. Emularea este singurul mecanism disponibil de virtualizare a procesorului atunci cand ISA clientului este diferit de ISA gazdei.

A doua metoda de virtualizare a procesorului foloseste executarea nativa directa pe masina gazda. Aceasta metoda este posibila doar daca ISA gazdei este identica cu ISA clientului si chiar si in acest caz doar in anumite conditii. Este oricand posibila construirea unei masini virtuale folosind emularea, insa, chiar si cu tehnici sofisticate precum translatia binara, performanta unui program pe masina virtuala va ajunge rar la performanta programului rulat pe un hardware nativ.

Analiza originala facuta de Popek si Goldberg se referea la sisteme de generatia a treia, precum IBM System/370, Honeywell 6000 si Digital PDP-10, dar ramane valabila si pentru sistemele de astazi (desi din perspectiva ISA putem spune ca suntem inca in generatia a treia). Presupunerile facute in analiza erau:

Partea hardware este compusa dintr-un procesor si o memorie uniform adresabila

Procesorul poate opera in unul din cele doua moduri(modul sistem si modul user)

anumita parte din instructiuni este disponibila fie in modul sistem fie in modul user;

23

Masini Virtuale

Adresarea memoriei este facuta relativ la continutul unui registru de realocare (ex. O valoare fixa este adaugata la o adresa virtuala pentru a ajunge la o adresa de memorie fizica).

MemoriaIntr-un sistem de VM fiecare din clientii VM are propriul set de tabele

de tabele de memorie. Translatarea adresei din fiecare din VM clienti transforma adresel in adrese virtuale catre locatii in memoria reala(memoria reala corespunde memoriei fizice pe o platforma nativa, insa pe o platforma VM acest lucru nu se intampla). Intr-un sistem de VM, adresele din memoria reala a clientului sunt mapate pentru a determina adrese din memoria fizica al hardwareului gazda.

Memoria fizica este memoria hardware. Memoria reala este iluzia a memoriei fizice perceputa de un client VM (aceasta iluzie este sustinuta de VMM care mapeaza memoria reala a clientului la memoria fizica). Este aceasta mapare fizic-real cea care implementeaza virtualizarea memoriei in tr-un sistem VM.

Adaugarea unui alt nivel in ierarhia moemoriei duce la necesitatea unor mecanisme aditionale pentru managementul memoriei. De notat este faptul ca marimea totala adunata a tuturor clientilor este in general mai mare decat marimea memoriei fizice a sistemului. Astfel, VMM mentine un spatiu de swap, distinct de spatiile de swap a fiecarui client. VMM gestioneaza memoria fizica schimband paginile reale ale clientilor in si din propiul spatiu de swap.

Concluzii

24

Masini Virtuale

Trebuie facute anumite mentiuni cand vorbim de virtualizarea unui multiprocesor. Trebuie luat in seama faptul ca atunci cand vorbim de un singur procesor, virtualizarea se face prin time sharing-ul resurselor singurului procesor. Cu multiprocesor, virtualizarea se poate face prin impartirea multiplelor procesoare intre sistemele virtuale. Optiunea dintre time sharing si partitionare (sau folosirea amandurora) aduce alternative de design pe baza virtualizarii multiprocesorlui.

Sistemele de VM s-au bucurat de o mare popularitate in ani 70 si 80, dar au parut ca se sting spre anii 90 odata ce calculatoarele single-user au devenit mai ieftine si accesibile. Recent s-a reinnouit interesul pentru sisteme virtuale, mai ales in partea de web, odata cu nevoia unui numar masiv de sisteme simple single-thread (care tebuiesc foarte rar sa comunice intre ele dar care impart resurse de stocare). Pentru aceste aplicati, masinile virtuale tind sa utilizeze resursele procesorului in locul clusterelor mari de uniprocesoare. Masinile virtuale reduc in acelasi timp costurile prin faptul ca a inchide sau a deschide o masina virtuala este foarte facil.

Desi popularitatea initiala a masinilor virtuale se datora abilitatii de a permite useri multiplii sa foloseasca un sistem sofisticat ca si cum ar fi fost al lor, folosirea masinilor virtuale in viitor se va datora altor factori. Exista probleme in curs de dezvoltare, cum ar fi securitatea şi incapsulare de sistem, modele emergente, cum ar fi Grid, care vor spori gradul de utilizare a tehnologiei de masini virtuale.

25

Masini Virtuale

Bibliografie1. http://en.wikipedia.org/wiki/Virtual_machine

2. http://en.wikipedia.org/wiki/Java_Virtual_Machine

3. Smith, James E. - Virtual Machines: Versatile Platforms for Systems and Processes (The Morgan Kaufmann Series in Computer Architecture and Design)

26