Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Tesi di laurea Un Architettura per il Monitoraggio on-line Anno Accademico 2005/2006 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Salvatore Orlando candidato Rinaldi Ciro matr. 534/926
Dedica Alla mia Famiglia. La scienza è fatta di dati come una casa di pietre. Ma un ammasso di dati non è scienza più di quanto un mucchio di pietre sia una casa. -Jules Henri Poincaré
Indice 1 La Java Virtual Machine, il Problema dell' Adabilità 1 1.1 Introduzione............................ 1 1.2 L'Architettura........... 3 1.2.1 Il ClassLoader....................... 3 1.2.2 La Gestione della Memoria Heap, la Garbage Collection 4 1.2.3 Principali Algoritmi di Garbage Collection....... 6 1.2.4 La Java Virtual Machine ed il Compilatore HotSpot.. 7 1.2.5 Java Threads....................... 9 1.2.6 Execution Engine..................... 9 1.2.7 Error Handling...................... 11 1.3 Classicazione dei Fallimenti... 12 1.4 Conclusioni............................ 16 2 Il Problema del Monitoraggio nel Contesto della Java Virtual Machine 17 2.1 Metodologie per lo Studio di Adabilità............ 17 2.1.1 Measured-based Analysis................. 19 2.1.2 Dependability Benchmarking.............. 19 2.1.3 Error Injection...................... 21 2.1.4 Robustness Testing.................... 22 2.1.5 Aging Analysis...................... 23 iii
2.2 Tecniche e Tecnologie per il Monitoraggio............ 24 2.2.1 Java Virtual Machine Tool Interface........... 24 2.2.2 Java Management extensions.............. 27 2.2.3 Bytecode Injection.................... 31 2.3 Tools di Monitoraggio...................... 34 2.3.1 ej-technologies, JProler................. 34 2.3.2 Sun Microsystems, HPROF: Heap Proler....... 35 2.4 Conclusioni............................ 36 3 JVMMon: Un Sistema di Monitoraggio Orientato alla Diagnosi 38 3.1 Introduzione a JVMMon..................... 38 3.2 Funzionalità Oerte........................ 39 3.3 Architettura............................ 40 3.3.1 JVMTI Agent....................... 42 3.3.2 Local Monitor Daemon.................. 43 3.3.3 Data Collector...................... 43 3.4 Soluzioni di Design........................ 44 3.4.1 Descrizione dell' Agente JVMTI............. 46 3.4.2 Instrumentation Tool, (Agente Java).......... 49 3.4.3 Communication Layer.................. 53 3.5 Valutazione Sperimentale..................... 54 3.5.1 Obiettivo delle Misure.................. 54 3.5.2 Testbed Utilizzato.................... 54 3.5.3 Risultati.......................... 55 3.6 Conclusioni............................ 57 Appendice 60 A 60 iv
Elenco delle gure 1.1 Fasi del Class Loading...................... 3 1.2 Execution Engine......................... 10 1.3 Fault Classication........................ 14 2.1 Analisi dei Fallimenti del Tandem System........... 18 2.2 Dependability Scenario...................... 20 2.3 Virtual Machine.......................... 21 2.4 JMX Tiered Architecture..................... 29 2.5 Trasformazione di classi a Load Time.............. 32 2.6 Esempi di funzionamento di JProler.............. 35 3.1 Java Virtual Machine Heap................... 39 3.2 Architettura di JVMMon..................... 41 3.3 Evoluzione dello Stato della Virtual Machine.......... 45 3.4 Object Hot Swapping....................... 52 3.5 Overhead introdotto da JVMmon................ 56 3.6 Performance Overhead, comparativa tra JVMMon ed HPROF 56 3.7 Memory Footprint Comparison................. 59 v
Elenco delle tabelle 3.1 Formato del Local Log File dell'agente JVMTI......... 42 vi
Capitolo 1 La Java Virtual Machine, il Problema dell' Adabilità 1.1 Introduzione E' indubbio che la piattaforma Java, negli ultimi anni, è divenuta sempre più utilizzata, anche in scenari profondamente diversi, grazie soprattutto, ad alcune su caratteristiche peculiari quali: l'alto livello di portabilità, le astrazioni di programmazione ed in generale, grazie alle migliorie ed evoluzioni della piattaforma stessa. Attualmente non è dicile riscontrare l'uso della piattaforma nell'ambito di applicazioni cosidette critiche, come sistemi Real Time, applicazioni transazionali, i sistemi di controllo remoto. Tuttavia la JVM non possiede (almeno nelle attuali implementazioni) nessun supporto diretto alla Fault Tolerance. Per poter sviluppare dei sistemi capaci di essere tolleranti ai guasti, è necessario riuscire ad interpretare il comportamento della con riferimento agli errori ed ai fallimenti che si manifestano. Questa analisi, presentata successivamente, ci ha permesso di ssare dei focus, su cui focalizzare l'attenzione, nello sviluppo di una unità di monitoraggio della JVM; lo sviluppo di tale monitor, è da considerarsi come un primo passo 1
verso la progettazione di una JVM in grado di tollerare un buon numero di situazioni anomale, di gestirle, e quindi di proseguire nelle sue attività senza andare in crash, o comunque, in un qualsisi stato in cui l'adabilità dei risultati dell'elaborazione della stessa siano inattendibili oppure, addirittura, completamente errati. 2
1.2 L'Architettura 1.2.1 Il ClassLoader Figura 1.1: Fasi del Class Loading Il sottosistema, incaricato di cercare e caricare i tipi, è il Class Loader Subsystem. La Java Virtual Machine comprende due tipi di Class Loaders: un Bootstrap Class Loader e gli User Dened Class Loaders; Il primo, è parte dell'implementazione della JVM, gli User Dened, invece, sono parte dell' applicazione Java in esecuzione. In realtà va chiarito che, oltre a localizzare ed importare i dati binari per le classi, i Class Loader sono anche responsabili di vericare la correttezza delle classi importate, di allocare ed inizializzare la memoria per le variabili delle classi ed inoltre partecipano a risolvere i riferimenti simbolici; in particolare è possibile identicare queste tre fasi del processo di Class Loading 1.1: 1. Loading: vengono localizzati ed importati i dati binari di una classe. 2. Linking: Verica: ci si assicura della correttezza del tipo importato; 3
Preparazione: si alloca memoria per le variabili della classe e la si inizializza ai valori di default; Risoluzione: si trasformano i riferimenti simbolici in riferimenti diretti; 3. Initialization: viene invocato il codice Java che inizializza le variabili della classe ai valori iniziali. 1.2.2 La Gestione della Memoria Heap, la Garbage Collection Il processo della Garbage Collection comporta la liberazione delle risorse utilizzate da oggetti non più referenziati dall'applicazione in esecuzione. La specica Java non impone, nella scelta delle tecniche e degli algoritmi di Garbage Collection, alcun vincolo. Il Garbage Collector deve, in qualche modo, determinare quali oggetti non sono più referenziati da una applicazione e rendere riutilizzabile lo spazio, della memoria heap, occupato dai suddetti oggetti. Tra l'altro, compito del Garbage Collector è quello di combattere il fenomeno della frammentazione dell'area heap. Esistono, chiaramente, una serie di vantaggi indiscussi sfruttando un approccio gestito della memoria; tra questi sicuramente possiamo annoverare l'incremento di produttività e la salvaguardia automatica della memoria, evitando così crash accidentali derivanti da una erronea gestione delle risorse da liberare. In contrapposizione ai suddetti vantaggi, vanno segnalati anche alcune problematiche che emergono nella gestione automatica della memoria: bisogna tener conto dell'overhead introdotto dal dover iterare costantemente l'albero dei riferimenti degli oggetti; l'aleatorietà con cui il processo di Garbage Collection viene schedulato [10]. 4
Ogni Garbage Collector deve fondamentalmente eseguire due mansioni: Riconoscere gli oggetti da segnalare per la Garbage Collection. Liberare spazio nell'area Heap. La Garbage Detection tipicamente è eettuata denendo un set di root references e determinando la reachability (raggiungibilità) dai roots; un oggetto è raggiungibile se esiste almeno un percorso, attraverso i references, dai roots attraverso cui è accedibile da un programma in esecuzione. Tutti gli oggetti che sono accedibili dai roots sono considerati live, altrimenti Garbage. 5
1.2.3 Principali Algoritmi di Garbage Collection Reference Counting : è stata la prima strategia di Garbage Collection implementata nella Hot Spot. In questo approccio, un contatore, detto reference count, è mantenuto per ogni oggetto presente nell'heap. Quando un oggetto viene creato ed un riferimento ad esso viene assegnato ad una variabile, il counter dell'oggetto viene settato ad uno. Quando un'altra variabile assegna un riferimento a quell'oggetto, il contatore dell'oggetto viene incrementato; se invece un riferimento ad un oggetto esce dall'ambito della visibilità oppure è assegnato un nuovo valore, il contatore viene decrementato. Ogni oggetto, il cui contatore è settato al valore zero, viene segnalato per la garbage collection. La semplicità di implementazione di questa tecnica si scontra con il difetto di non riuscire ad identicare i cicli di riferimenti, ad esempio: Tracing Collectors: investiga il grafo dei riferimenti agli oggetti iniziando dai nodi roots; gli oggetti, a mano a mano che vengono ispezionati, sono marcati settando un ag (direttamente nell'oggetto oppure attraverso una bitmap). Quando il tracing è completo, gli oggetti privi del ag sono segnalati come unreachable e possono essere garbage collected. Compacting Collectors: I Garbage Collectors dovrebbero, tra l'altro, tentare di combattere il fenomeno della frammentazione dell'area Heap, problema comune alle MMU (Memory Management Unit) dei sistemi operativi. Due delle strategie maggiormente in voga sono la compattazione e la copia. Entrambe le tecniche spostano oggetti on the y per ridurre la frammentazione dell'heap. I Compacting Collectors spostano gli oggetti in stato live attraverso lo spazio libero nell'heap no alla ne; i riferimenti degli oggetti spostati vengono poi aggiornati. Uno modo per semplicare l'aggiornamento dei references è quello di aggiungere un livello di indirizzamento indiretto. Copying Collectors: questi collectors invece, spostano tutti gli oggetti, in stato live, in una nuova area e li pongono spalla a spalla eliminando la 6
frammentazione della suddetta area; la area precedentemente occupata viene segnalata come libera. Una tecnica abbastanza comune, tra i Copying Collectors, è la Stop And Copy. In questo approccio l'area heap viene divisa in due regioni, di queste, se ne utilizza solo una alla volta. Quando lo spazio di quella in uso termina, l'esecuzione del programma viene messa in stop, tutti gli oggetti della prima regione vengono travasati nella seconda side by side. Al termine della copia viene ripresa la normale esecuzione del programma. Parallel Collectors: The new collectors in JDK 1.4.1 are all designed to address the issue of garbage collection on multiprocessor systems. Because most garbage collection algorithms stop the world for some period of time, a single-threaded garbage collector can quickly become a scalability bottleneck, because all but one processor are idle while the garbage collector has suspended the user program threads. Two of the new collectors are designed to reduce collection pause time the parallel copying collector and the concurrent mark-sweep collector. The other, the parallel scavenge collector, is designed for higher throughput on large heaps. 1.2.4 La Java Virtual Machine ed il Compilatore HotSpot La Java HotSpot Virtual Machine costituisce l'implementazione Sun della specica della VM. Alcune delle caratteristiche più interessanti, come visto in [8, 9] dell'architettura sono: Frame interpretati, compilati e nativi sullo stesso Stack. Preemptive multithreading basato su Thread Nativi. Generational e Compacting Garbage Collection. 7
I compilatori JIT (Just-in-Time) sono essenzialmente tradizionali compilatori che traducono, il Bytecode Java in codice nativo per il processore host, al volo. Ovviamente bisogna tenere conto del fatto che, il compilatore JIT, girando a user-time, è soggetto ad un signicante delay che rallenta sicuramente la fare di startup dell'applicazione. Inoltre va considerato che la compilazione JIT potrebbe avere eetti abbastanza attenuati in Java, rispetto ad altri linguaggi come C/C++, a cause dei seguenti fattori: In Java tutti gli oggetti vengono allocati nello Heap ( diversamente da C++, dove alcuni oggetti giacciono nullo stack), da ciò deriva un tasso medio di allocazioni degli oggetti più alto, se comparato con quello in C++; va poi tenuto in considerazione che Java è un linguaggio Garbage Collected, quindi soggetto a diversi tipi di memory allocation overhead. In Java moltissimi metodi sono dichiarati virtual, ovvero, potenzialmente polimor. Le dicoltà che sono emerse, vengono risolte dall'architettura HotSpot mediante Adaptive Optimization, attraverso tre tecniche: HotSpot Detection: L'ottimizzazione adattativa risolve i problemi della JIT compilation avvantaggiandosi una interessante proprietà della maggior parte dei programmi. Virtualmente tutti i programmi passano la maggior parte del tempo di esecuzione eseguendo un piccola parte del codice. Il compilatore HotSpot analizza il codice, mentre lo esegue, per localizzare le aree critiche del programma; identicate queste aree critiche procede ad una ottimizzazione nativa delle stesse per migliorare le performance. Method Inlining: ha importanti beneci; riduce drammaticamente la frequenza delle invocazioni dei metodi. Ancora più importante, produce grossi blocchi di codice su cui è possibile eettuare ottimizzazione. 8
Dynamic Deoptimization: Il caricamento dinamico complica sensibilmente le procedure di inlining, poiché cambia le relazioni globali all'interno del programma (infatti il method inlining è un tecnica di analisi globale); una classe appena caricata infatti, potrebbe contenere dei metodi per cui è necessario l'inlining. La Java Hot Spot VM è capace di deottimizzare ed eventualmente ri-ottimizzare hot spots precedentemente ottimizzati. La Java Virtual Machine prevede due distinti modi di funzionamento: Client e Server; entrambi i modi di funzionamento sono simili, ma il modo server è ottimizzato per l'esecuzioni di applicazioni nel lungo periodo, applicazioni per le quali non è importante una fase di starup estremamente rapida, bensì una esecuzione del codice molto rapida. La Client VM, invece, è specializzata nel ridurre i tempi di startup e l'occupazione di memoria; queste caratteristiche la rendono particolarmente adatta a sistemi tipo client. 1.2.5 Java Threads In Java la gestione dei thread è eettuata associando i thread del sistema operativo host con ogni thread della VM in rapporto 1:1 Sia i metodi Java che quelli nativi condividono lo stesso stack, consentendo chiamate veloci tra applicazioni Java ed applicazioni C. I thread java sono fully preemptive, e supportati dal meccanismo di schedulazione del sistema operativo host. Uno dei vantaggi fondamentali dell'uso di thread nativi, e della loro schedulazione, è poter sfruttare le caratteristiche di multithreading, del sistema operativo, in modo trasparente. 1.2.6 Execution Engine La specica impone che ogni implementazione della specica, deve avere l'abilità di eseguire il bytecode Java (bc). La 9
Figura 1.2: Execution Engine tecnica più semplice che è possibile pensare, implementata nella prima JVM della SUN, è l'interpretazione del bytecode one a time; un'altra tecnica di esecuzione è la cosidetta JIT (Just-In-Time) Complilation. La tendenza, nell'ultimo periodo, è rivolta ad un approccio combinato, ibrido, detto Adaptive Optimization. Una Virtual Machine con ottimizzatore adattativo inizia ad eseguire una applicazione Java interpretando tutto il codice, ma monitorando l'esecuzione dello stesso. La maggior parte dei programmi passa il novanta percento del proprio tempo eseguendo circa il dieci percento del codice; monitorando l'esecuzione dell'applicazione, la virtual machine riesce a determinare quali sono gli Hot Spot. Nel momento in cui la VM stabilisce che un metodo è un Hot Spot avvia un thread incaricato di compilare il bytecode, di detto metodo, in nativo e di ottimizzarlo sfruttando alcune delle tecniche osservate in precedenza. Il fatto di selezionare dinamicamente il codice da compilare in nativo, costituisce in ogni caso una miglioria rispetto alla compilazione JIT tradizionale. 10
1.2.7 Error Handling Il momento ideale per catturare un errore è a tempo di compilazione; sfortunatamente non tutti gli errori possono essere riscontrati in questa fase. Con il termine Exception si intende Exceptional Event; una eccezione è un evento che si manifesta durante l'esecuzione di un programma alterando il normale usso d'esecuzione dello stesso. Quando si manifesta un errore in un metodo, la VM crea un oggetto d'eccezione e lo passa al sistema di runtime. Tale oggetto contiene informazioni circa l'errore, includendo il tipo e lo stato del programma. Nel momento in cui un metodo solleva una eccezione, il runtime system cerca di trovare qualcosa per gestirlo scorrendo la lista, ordinata, dei metodi che hanno portato il sistema nello stato di errore; questa lista è detta Call Stack. Il runtime system cerca, ricorsivamente, nel call stack, un metodo che contenga un blocco di codice che possa gestire l'eccezione. Questo blocco è detto Exception Handler. Quando viene identicato un handler opportuno, il runtime system passa l'eccezione all'handler. Se, dopo una ricerca esaustiva attraverso tutti i metodi sul call stack, non è possibile rintracciare un handler opportuno, viene invocato il Thread.dead, il programma termina e la VM va nello stato VMDeath 1. L'uso delle Eccezioni nella gestione degli errori è indubbiamente vantaggiosa, infatti permette di: Separare il codice di gestione degli errori dal regular code. Propagare gli errori in cima al call stack. Raggruppare e dierenziare i diversi tipi di errori. Una distinzione delle eccezioni presenta questa struttura: 1 Si veda in proposito la documentazione relativa a JVM TI: Java Virtual Machine Tool Interface, ove vengono descritti gli eventi principali atti a descrivere il comportamento e lo stato della JVM. 11
(a) (b) 1.3 Classicazione dei Fallimenti della Java Virtual Machine Checked Exception: sono condizioni eccezionali che un applicazione well-written dovrebbe anticipare e recuperare. Le Checked Exception sono soggette al vincolo del Catch/Specify; tutte le eccezioni sono checkd tranne quelle indicate da Error, RuntimeException e le loro sottoclassi. Errori: sono quelle condizioni eccezionali esterne all'applicazione, e che tipicamente l'applicazione non può né anticipare né recuperare. Runtime Exception: sono quelle condizioni eccezionali interne all'applicazione e che l'applicazione non può né anticipare né recuperare. Sono un sintono di un bug della programmazione, inteso come errore logico, oppure dovuto ad un errato uso delle API. Errors e Runtime Exceptions sono dette anche Unchecked Exception. L'unica sorgente di informazioni circa i Fallimenti, attualmente disponibile, è il Bug Database, disponibile su http://bugs.sun.com. Le informazioni, in esso contenute, sono state fornite da utenti, nonostante questo, è possibile dimostrare che come costituisce un punto di inizio per 12
un'analisi dei fallimenti della JVM. Anzitutto è fondamentale stabilire dei criteri attraverso cui analizzare i dati, e quindi classicare i fallimenti sulla base di questi. Una possibilità è la seguente; distinguere, secondo [5], i fallimenti in: 13
Figura 1.3: Fault Classication 14
Failure Manifestation: VM Error Message: Eccezioni sollevate da un programma Java. OS Error Message: Errori del livello Sistema Operativo riportati all'utente, magari sotto forma di SIGNAL. Hang / Deadlock: Sono quegli scenari che non portano ad un crash della JVM, ma l'applicazione in esecuzione, oppure una sua parte, va in stallo. Silent Crash: La JVM entra nello stato VMDeath senza alcun report all'utente. Computation Error: I risultati ottenuti sono diversi da quelli attesi. Failure Source: Execution Unit OS Virtualizazion Layer Memory Management Unit (MMU) System Service Unit Severity: Un fallimento è denito catastroco se porta al crash della JVM. Un fallimento è detto non catastroco se la JVM continua nella sua esecuzione nonostante il fallimento. Environment: Sono quei fallimenti classicati in base alla correlazione della JVM con l'ambiente in cui essa è in esecuzione. VM Activity: E' la classicazione dei fallimenti correlata al workload cui è sottoposta la JVM. Failure Frequency: E' la classicazione stilata sulla base della frequenza con cui un certo fallimento occorre. 15
1.4 Conclusioni Come gia menzionato, la piattaforma Java ormai è presente in una moltitudine di contesti, alcuni dei quali particolarmente critici; E' stata anche ricordata la mancanza di supporto diretto alla Fault Tollerance; il connubio di questi due fattori, genera un problema grave e che urge arontare: Valutare il grado di robustezza e delle applicazioni Java. 16
Capitolo 2 Il Problema del Monitoraggio nel Contesto della Java Virtual Machine 2.1 Metodologie per lo Studio di Adabilità Applicazioni speciche per il monitoraggio di un paziente, per il controllo di processo, per l'online transaction processing, possiedono una forte connotazione di continuità di servizio; Ciò è ancora più vero se consideriamo che statisticamente i periodi di non funzionamento sono concentrati durante il picco di domanda. Queste applicazioni richiederebbero sistemi, virtualmente, infallibili, o ciò che è lo stesso, che parti del sistema possano fallire senza compromettere la disponibilità di fornire il servizio.risulta ovvio quindi, che negli ultimi decenni lo studio dell'adabilità dei sistemi informatici ha rivestito un ruolo primario sia nella comunità scientica che industriale. In particolare una analisi condotta da Jim Grey, e presentata in [4], dimostra come la percentuale più alta di fallimenti in un sistema sia dovuta al software e non al resto della piattaforma. La stessa analisi mostra lo stesso risultato 17
anche in termini di MTBF (Mean Time Between Failures ), in Figura 2.1 una sintesi dei risultati. Figura 2.1: Analisi dei Fallimenti del Tandem System Nel corso degli anni sono state sviluppate diverse metodologie per lo studio dei sistemi informatici esposti di seguito. 18
2.1.1 Measured-based Analysis Questa tecnica è in assoluto la più famosa tra i lavori connessi alla dependability analysis; l'idea è molto semplice: monitorare un sistema per ottenere dati circa i suoi fallimenti. Nella letteratura sono stati proposti molti modelli utili per modellare l'adabilità dei sistema sotto analisi partendo dai dati raccolti circa i fallimenti; in questi lavori è mostrato anche come, partendo dai suddetti dati, è possibile creare modelli sui fallimenti e sull'adabilità. Esempi di questa tecnica sono presenti in letteratura, come in [11]. Tuttavia questa tecnica non è particolarmente adatta allo studio dell'adabilità della Java Virtual Machine, non perchè il monitoraggio della JVM sia complesso, ma bensì, perchè i tempi di osservazione necessari a raccogliere un suciente numero di stati con livelli di workload ordinari sarebbero troppo elevati. Per poter utilmente sfruttare questa tecnica, dovrebbero essere pensati dei workloads specici, attività troppo complessa, soprattutto considerando che esistono numerose soluzioni diverse. 2.1.2 Dependability Benchmarking Il concetto di Dependability Benchmarking si allontana sostanzialmente da quello di Performance Benchmarking; in questi ultimi, diversi tipi di workloads sono imposti sul sistema da testare. Una apposita unità di monitoraggio fornirà i dati di misura estratti dagli esperimenti. Nei dependability benchmarks invece, al sistema vengono imposti sia un set di workloads che di faultloads vedi [7]. Ogni esperimento è costituito dall'imposizione di un workload, per simulare una condizione di funzionamento del sistema, e dall'iniezione di un fault estratto da un certo set di faultload. Tipicamente ogni dependability benchmark è costituito dai seguenti elementi vedi Figura 2.2: Benchmark Target : su cui vengono eettuate le misure Fault Injection Target : dove vengo iniettati i fault 19
Workload : per imporre una condizione di funzionamento Faultload : per portare il sistema in uno stato di cattivo funzionamento Monitor : per estrarre le misure dell'esperimento Analyzer : per fare analisi dei risultati ottenuti. Figura 2.2: Dependability Scenario I workloads, eseguiti sul sistema da testare, sono alterati con uno dei fault estratto dal set di faultloads. Le misure di adabilià, come la percentuale di fallimento, sono estratti dal target a mezzo dell'unità di monitoraggio. Un esempio molto rilevante di Dependability Benchmark è sicuramente DBench, un framework sviluppato per valutare l'adabilità di sistemi COTS e COTSbases. Il Dependability Benchmarking sembrerebbe essere interessante per studiare l'adabilità di una virtual machine; diversamente da altri sistemi software, l'adabilità di una macchina virtuale è compromessa sia dalle applicazioni che vengono eseguite su di essa, sia dal sistema operativo host come si evince dalla Figura 2.3. Risulta chiaro che esiste un nuovo scenario di analisi: ci saranno misure di robustezza sull'applicazione e di sensibilità del sistema operativo, ottenute attraverso: 1. Fault Injections nell'applicazione in esecuzione sulla virtual machine 20
Figura 2.3: Virtual Machine 2. Monitoraggio dei risultati Esperimenti mostrano che i sistemi di gestione delle eccezioni e di verica, built-in nella Java Virtual Machine, sono in grado di tollerare condizioni di funzionamento anomale dell'applicazione che è in esecuzione. L'analisi quindi, si deve spostare sul layer sottostante e alle interazioni tra la virtual machine e sistema operativo. Anche in questo caso risulta lampante l'importanza di possedere una unità di monitoraggio capace di mostrare questi dati, ed un modulo di analisi capace di interpretarli. 2.1.3 Error Injection Un approccio, teso ad accelerare il processo di fallimento, potrebbe essere iniettare errori al posto dei faults; questa tecnica però, richiede un esatto mapping tra i software faults ed gli errori. Deve essere assicurato che gli errori iniettati emulino esclusivamente i faults di origine software e non rispecchino fallimenti dell'hardware [6]. Le tecniche basate su Fault Emulation attraverso error injection garantiscono che l'errore iniettato sia rappresentativo di un fault. A causa della natura qualitativa delle fonti (essenzialmente i bug databases), è dicile denire un prolo di error injection coerente con l' Orthogonal Defect Classication (ODC); un ricerca approfondita nei bug da- 21
tabases non è stata suciente ad identicare sorgenti di fault che interessassero direttamente la Java Virtual Machine. Sarebbe necessario sviluppare una nuova classicazione ad hoc per il caso ; va notato però, che una analisi di questo tipo, risulterebbe applicabile esclusivamente a detto caso e dicilmente riapplicabile ad altri sistemi software. 2.1.4 Robustness Testing L'idea di Robustness Testing è stata proposta per la prima volta da Siewiorek e Koopman in [2]. L'idea di base è che un sistema software, supposto bug free, possa fallire. Questo approccio consiste nel fatto che è praticamente impossibile testare ogni singolo modulo di un sistema software, con ogni possibile dato di ingresso. Un esempio di Tool per il Robustness Testing è Ballista; sostanzialmente il testing avviene in quattro fasi: 1. Selezione del modulo da testare 2. Identicare l'iterfaccia (servizio) esposta da questo modulo 3. Forzare il modulo selezionato con dati di ingresso validi e non 4. Analizzare il comportamento del sistema, nel caso di Ballista, del sistema operativo. Il Robustness Testing sembra interessante nel contesto della analisi di adabilità ; Per eettuare questo tipo di test bisognerebbe: identicare le interfacce tra le applicazioni Java e la virtual machine (quindi il ByteCode Interpreter e la Native Interface). L'idea, sostanzialmente corretta, si scontra però con un problema di natura implementativa; la tecnica di collaudo esposta da Siewiorek non tiene conto dello stato interno del sistema da testare, è sostanzialmente un collaudo black-box, ciò rende la tecnica non adatta al contesto. Sulla base di questa considerazione è possibile fare almeno due osservazioni: 22
1. Bisogna Monitorare lo stato 2. E' necessario realizzare una forma di collaudo tipo white-box ; una buona soluzione potrebbe essere una mirata bytecode injection. 2.1.5 Aging Analysis Il termine Software Aging è stato introdotto da Kintala e Huang nel 1997 in []. Il fenomeno dell'invecchiamento si verica quando alcune risorse utilizzate da una applicazione sono soggette a depletion (utilizzate no in fondo): Esempi classici di questo fenomeno sono i memory leaks, buer overows, oating point errors. Un Aging Fault viene attivato diverse volte a causa dell'accumularsi degli errori, questo porta ad un fallimento del sistema. Gray in [4] espone una classicazione degli aging faults dove esistono: HeisenBugs: sono quei bugs che scompaiono durante la loro ricerca a causa anche di piccolissime perturbazioni introdotte dal bugcathcer BohrBugs: sono quei bugs che portano sempre il sistema in uno stato di cattivo funzionamento allorchè una certa operazione viene eettuata. Studi di invecchiamento su server SOAP-based sono stati proposti da Madeira in [3]; un altro caso di studio interessante circa l'aging in un webserver è proposto in [1]; in questo studio viene proposto un modello numerico attraverso cui predire il momento più adatto per bloccare il sistema, ed assicurasi quindi il ringiovanimento dello stesso. Nel corso del tempo diverse metodologie sono state messe a punto per identicare il fenomeno dell'aging e per prevdere il Time-To-Resuorce-Exhaustion. Nel caso specico della Java Virtual Machine è possibile arguire che i componenti interessati dal fenomeno dell'aging sono: il Runtime System, il Reference Handler ed il Compilatore JIT e nell'interfaccia con il sistema operativo. 23
2.2 Tecniche e Tecnologie per il Monitoraggio Le principali tecnologie disponibili per eettuare il monitoraggio di applicazioni Java, e della stessa Virtual Machine sono: JVM TI (Java Virtual Machine Tool Interface), JMX (Java Management Extensions) e le tecniche BCI (ByteCode Injection). 2.2.1 Java Virtual Machine Tool Interface La JVM TM Tool Interface è una interfaccia di programmazione utilizzata dai tools di sviluppo e monitoraggio. Fornisce dei meccanismi per sondare lo stato e controllare l'esecuzione di applicazioni Java TM. JVM TI è una inferfaccia two-way; un client JVM TI, d'ora in avanti chiamato agent 1, può essere informato di interessanti occorrenze attraverso eventi. JVM TI può interrogare e controllare l'applicazione attraverso molteplici funzioni, alcune in risposta ad eventi ( e vengono dette callbacks ), altre indipendenti da questi. Gli agenti vengono eseguiti nello stesso processo e comunicano direttamente con la Virtual Machine che sta eseguendo l'applicazione da esaminare. La comunicazione avviene attraverso una interfaccia nativa. Tipicamente gli agenti sono abbastanza compatti, e possono essere controllati da un processo separato senza interferire con la normale esecuzione dell'applicazione target. Un tool di monitoraggio può essere scritto utilizzando direttamente JVM TI, oppure attraverso una interfaccia di alto livello. Gli agenti possono essere scritti in qualsiasi linguaggio nativo che supporti le convenzioni per le chiamate del linguaggio C e le denizioni C/C++. Le denizioni delle funzioni, tipi di dato, eventi e costanti sono contenute nell'header le jvmti.h; per utilizzarle è suciente aggiungere: 1 Di un agente JVM TI viene eettuato il Deploying nella forma di Shared Library:.so,.dylib... 24
#include <jvmti.h> al proprio codice. La libreria, ossia l'agente, deve esportare una funzione di start-up con il seguente prototipo che costituisce una sorta di entry-point per la libreria: JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM* vm, char* options, void* reserved) Questa funzione sarà invocata dalla VM al momento del caricamento della libreria. La VM dovrebbe caricare la libreria durante le primissime fasi dell'inizializzazione della VM, quando: le system properties vengano impostate l'intero set di capabilites è ancora raggiungibile 2 nessun bytecode è stato eseguito nessuna classe è stata caricata non è stato creato nessun oggetto Il valore di ritorno da Agent_onLoad è utilizzato per segnalare un errore. Ogni valore diverso da zero indica un errore e causa la terminazione della VM. La libreria potrebbe, opzionalmente, esportare una funzione di shutdown con il seguente prototipo: JNIEXPORT void JNICALL Agent_OnUnload(JavaVM* vm) Questa funzione verrà chiamata dalla VM quando la libreria sta per essere scaricata; è da notare la sostanziale dierenza tra la chiamata di questa funzione e l'occorrenza dell'evento VM_Death. Anchè l'evento VM_Death 2 le Capabilities, utilizzate per impostare la VM, sono disponibili solo in questa fase del ciclo di vita della VM. 25
venga inviato, la VM deve aver completato la propria inizializzazione, deve esistere un environment JVM TI valido che abbia impostato una callback per questo evento, e che l'evento sia stato abilitato. Queste fasi non sono necessarie invece per la funzione Agent_OnUnload e, tra l'altro, questa viene invocata anche se la libreria viene scaricata per altre ragioni. La Specica JVM TI supporta l'uso di più agenti simultaneamente. Ogni agente possiede il proprio environment; ciò implica che lo stato JVM TI è separato per ogni agente (i cambiamenti ad un ambiente non condizionano gli altri). Lo stato di un ambiente JVM TI comprende: Event Callbacks un set di eventi abilitati le Capabilities memory allocation / deallocation hooks Nonostante gli stati JVM TI siano separati, gli agenti ispezionano e modi- cano lo stato condiviso della VM, quindi anche l'ambiente nativo nel quale sono in esecuzione; ciò di ripercuote sul fatto che un agente potrebbe perturbare i risultati di altri agenti o portarli al fallimento. La specica quindi, delega al programmatore la responsabilità di evitare stati di funzionamento anomali dovuti all'interazione di più agenti. L'interfaccia JVM TI fornisce supporto diretto alla ByteCode Instrumentation, ossia all'abilità di alterare le istruzioni bytecode della Java Virtual Machine che formano il programma. Tipicamente queste alterazioni consistono nell'aggiunta di eventi al codice - body - di un metodo; ad esempio l'aggiunta, all'inizio del corpo di un metodo, di una chiamata a myagent.methodentered(). Fino a quando le modiche sono puramente additive, queste non modicano ne lo stato ne il comportamento dell'applicazione. Considerando che il codice aggiunto è standard bytecode, la VM 26
può eettuare su di esso, come sul resto del codice dell'applicazione, ogni ottimizzazione che ritenga opportuna. L'instrumentazione può essere iniettata in uno di questi tre modi: Static Instrumentation: Il class le è instrumentato prima di essere caricato nella VM; questa tecnica è fortemente sconsigliata. Load-Time Instrumentation: Quando un class le è caricato dalla VM, i raw bytes del class le sono inviati, per l'instrumentazione, all'agente. L'eveno ClassFileLoadHook fornisce questa funzionalità. Dynamic Instrumentation: Una classe gia caricata, è modicata. Questa funzionalità è fornita dalla funzione RedefineClasss. In Appendice viene presentato un semplice esempio di agente JVM TI (SimpleAgent.dylib) che illustra le funzionalità esposte. 2.2.2 Java Management extensions La Java Management Extensions (JXM) API è uno standard per la gestione ed il monitoraggio do applicazioni e servizi. Denisce una architettura di gestione, dei patterns di progettazione, delle APIs e dei servizi per progettare soluzioni web-based, distribuite, dinamiche e modulari, atte a gestiore risorse Java. La tecnologia JMX è nativa al linguaggio Java; ore estensioni di gestione ecienti e leggere a funzioni Java. Consiste di un set di speci- che e tools di sviluppo per gestire ambienti Java e progettare soluzioni di gestione e monitoraggio per applicazioni e servizi. Fornisce funzionalità di Instrumentazione del codice, un modo semplice e standard di scrivere smart agent, di integrazione con middleware e sistemi di monitoraggio preesistenti. Usi tipici della tecnologia JMX sono: Consultare e modicare la congurazione di una applicazione 27
Raccogliere statistiche circa il comportamento di una applicazione e rendere queste disponibili. Noticare cambiamenti di stato e condizioni di errore. 28
Figura 2.4: JMX Tiered Architecture La tecnologia JMX è denita da una architettura multi-tier dove le risorse gestite e le applicazioni di gestione sono integrate di un approccio plug and play come mostrato in Figura 2.4. Una certa risorsa è instrumentata attraverso uno o più oggetti Java conosciuti come Maneged Beans (MBeans), registrati in un oggetto server noto come MBean server. In dettaglio: Il livello instrumentazione contiene gli MBeans e le loro risorse da gestire. Fornisce una specica per implementare risorse gestibili attraverso JMX; una risorsa è manageble se è sviluppata in Java (oppure possiede un Java wrapper) ed è stata instrumentata in modo tale da poter essere gestita da un applicazione JMX-compilant. Una risorsa può essere instrumentata in due modi: staticamente e dinamicamente; gli Standard MBeans sono oggetti Java conformi ad un denito pattern di programmazione (ad esempio devono avere un costruttore e dei metodi setters e getters). Un Dynamic MBean è conforme ad una interfaccia specica che ore più essibilità a runtime. Le componenti chiave a livello instrumentazione sono gli MBeans, il modello di notica e le MBeans metadata classes. 29
Standard MBeans: il più semplice da progettare ed implementare. La loro interfaccia di gestione è denita dal nome dei metodi. Dynamic MBeans: Implementano una specica interfaccia ed espongono la loro interfaccia di gestione a runtime. Notication Model: JMX denisce un generico modello di notica basato sul modello degli eventi Java. MBeans Metadata Classes: Queste classi contengono le strutture per descrivere tute le complonenti di una interfaccia di gestione di un MBean: attributi, operazioni, notiche e costruttori. Il livello Agente contiene gli agenti JMX usati per esporre gli MBeans. Fornisce una specica per implementare gli agenti, i quali controllano le risorse e le rendono disponibili alla gestione da applicazioni remote. Gli agenti JMX sono costituiti da un MBean server e da un set di servizi per controllare gli MBeans. I JMX Managers accedono agli agenti MBeans tramite un protocol adapter (RMI, SNMP, HTTP...). Le componenti fondamentali di un agente sono l'mbean server ed i Services: MBean server: Un registro di oggetti che sono esposti alle operazioni di gestione in un agente. Agent Services: Oggetti che possono eettuare operazioni di gestione su di un MBean registrato sul server. I seguenti agenti sono disponibili in J2SE 5.0: Dynamic Class Loader: Attraverso un servizio m-let riceve ed instanzia nuove classi e librerie native da arbitrarie locazioni remote. Monitors: Osserva il valore di un attributo degli MBeans e può noticare altri oggetti di cambiamenti di stato. 30
Timers: Forniscono un meccanismo di scheduazione. Relation Service: Denisce le associazioni tra MBeans e forza la cardinalità della relazione basandosi su tipi predeniti di relazioni. Il livello Manager contiene le componenti che abilitano le applicazioni di gestione a comunicare con gli agenti JMX. Fornisce le interfaccie per implementare JMX Managers. In Appendice viene presentato un semplice esempio di agente JMX che illustra le funzionalità esposte. 2.2.3 Bytecode Injection La Bytecode Transformation è una potente tecnica per estendere od adattare, dinamicamente, software Java utilizzando dei tranformers che automaticamente riscrive classi compilate. i Bytecode Transformers sono utilizzati per: Integrare componenti software sviluppati separatamente Instrumentare applicazioni a scopo di monitoraggio, debugging o pro- ling Estendere applicazioni con nuove funzionalità di sicurezza, controllo ed altro I transformers modicano software esistente attraverso un parsing automatico e la manipolazione di classi compilate rappresentate da classle. Le nuove funzionalità, che si vuole aggiungere al software, sono completamente disaccoppiate dall'applicazione target ed implementate direttamente nel trasformatore. Considerando che i Bytecode Transformers agiscono sui programmi compilati, sono in grado di consentire le cosiddette late adaptations / extensions nonstante il codice sorgente non sia disponibile. Esperimenti 31
mostrano le enormi potenzialità delle tecniche di bytecode injection anche, e soprattutto in sistemi software network-oriented. Nonostante il successo delle ricerche, ci sono alcuni aspetti critici che ostacolano l'accettazione delle tecniche BCI come strumento di sviluppo: La costruzione dei trasformatori richiede: una conoscenza estremamente approfondite della struttura della Java Classle Rappresentation e del ByteCode Instruction Set, la stesura di un insieme di regole che disciplinino la scrittura di detti trasformatori in modo che l'inserimento del bytecode sia sicura. Sorge il problema adesso, di stabilire quando eettuare l'inserimento del codice; per questo scopo sono state individuate tre casi: 1. Staticamente: i classle vengono modicati attraverso BCI prima di essere caricati nella Java Virtual Machine dal ClassLoader. 2. Load Time: con questo approccio i classle vengono modicati prima che la Java Virtual Machine possa accedere alla classe; una buona soluzione per implementare questa strategia è progettare un apposito ClassLoader che integri un trasformatore, ciò garantisce la correttezza del classle caricato nella virtual machine; questa strategia infatti, ha il vantaggio di servirsi, automaticamente, del meccanismo di verica del Classloader vedi Figura 2.5. Figura 2.5: Trasformazione di classi a Load Time 32
3. Full Dynamic: con questo approccio è possibile modicare una classe potenzialmente gia eseguita dalla Java Virtual Machine, attraverso la tecnica dell'hotswapping; modiche puramente additive, non creano nessuna alterazione nel comportamento e di tutto il software in esecuzione su di essa. La letteratura propone moltissime librerie per la bytecode injection, le più utilizzate sono sicuramente: BCEL (ByteCode Engeneering Library) e Javassist. Nel panorama delle librerie per BCI, tardano ad aacciarsi soluzioni di basso livello sulla falsa riga di java_crw_demo. 33
2.3 Tools di Monitoraggio Esistono, nel panorama del software commerciale e non, delle soluzioni per il monitoraggio ; nel corso della prossima sezione esamineremo due utilities: JProler e HPROF. Lo scopo è mostrare come questi tools non siano adatti ad un monitoraggio orientato alla raccolta di dati per scopi di Dependability Analysis. 2.3.1 ej-technologies, JProler JProler è un software commerciale orientato in modo particolare alla analisi delle performance di una applicazione in esecuzione sulla Java Virtual Machine. Si basa sostanzialmente su JVMPI (Java Virtual Machine Proling Interface) e JVMTI (Java Virtual Machine Tool Interface); questa scelta è stata eettuata per garantire compatibilità con le virtual machine 1.4.x. L'instrumentazione completa non è possibile sulle virtual machine 1.5.x, dove l'interfacca di proling è divenuta deprecated; In Figura 2.6 alcuni esempi d'uso di JProler: 34
Un'Architettura per il monitoraggio online (a) Pro ling Settings (b) Memory Usage Figura 2.6: Esempi di funzionamento di JPro ler 2.3.2 Sun Microsystems, HPROF: Heap Pro ler Heap Pro ler è essenzialmene una piccola demo fornita con i sorgenti allo scopo di dimostrare l'utilizzo dell'interfaccia JVMTI e le possibilità di instrumentazione fornite da java_crw_demo; tipicamente il suo uso è correlato a quello di un tool di visualizzazione dell'heap dump (Hat). 35