La politica di sospensione adottata da EXaM è necessaria per accedere allo stack del processo in esecuzione. Lo stack, rappresentato in JDI dalla classe com.sun.jdi.StackFrame, rappresenta lo stato dell’invocazione di un meto- do sullo stack di chiamate di un thread. Durante l’esecuzione di un thread, ogni volta che si entra o si esce dall’invocazione di un metodo, si esegue rispet- tivamente la push e la pop degli stack frame sul call stack del thread interessa- to. Il call stack di un thread è realizzato come un java.util.List di oggetti di tipo StackFrame, ottenibile con l’istruzione ThreadReference.frames(). Un’istanza di un oggetto di tipo StackFrame viene creata al momento della sospensione di un thread e distrutta appena il thread viene riattivato ed è per mezzo di questa istanza che si accede alle variabili locali di un metodo e al loro valore. La classe ThreadReference rappresenta un accesso diretto allo stato di un thread sulla Virtual Machine: attraverso un ThreadReference, è possibile osservare se il thread sia in stato di sospensione, se sia in esecuzione o se sia zombie.
In Figura 8.2 nella pagina seguente è rappresentato un sequence diagram che illustra i passi necessari ad accedere allo StackFrame della VM.
E’ possibile osservare che, dato un qualsiasi evento, JDI risale al thread che lo ha generato e, da qua, allo StackFrame con le informazioni interessanti. Una volta che si sia ottenuto lo StackFrame, è possibile anche determinare il tipo e la classe di appartenenza dell’oggetto chiamante e di quello chiamato
Figura 8.2: Un activity diagram per raffigurare alcune operazioni JDI
e verificare quindi, nell’ottica del monitoring effettuato da EXaM, se essi appartengano allo stesso package o a package diversi.
EXaM genera un file XML per ogni thread avviato, annotandovi ogni in- gresso e uscita dai metodi invocati dal thread. Infatti, gli eventi di cui si è fat- ta richiesta di notifica sono proprio ThreadStartEvent, MethodEntryEvent e MethodExitEvent.
Più dettagliatamente, EXaM chiede la notifica di questi tre eventi, do- podichè, al verificarsi dell’invocazione di un metodo da parte di un thread, crea il file relativo al thread nel caso questo non esista e traccia tutte le informazioni riguardanti la chiamata, quali il nome del metodo, la classe di appartenenza, i valori dei parametri e il tipo dell’oggetto restituito. La
Figura 8.3: La traccia relativa al thread 1
procedura di verificare che il file esista, prima della scrittura dei metodi in ingresso e in uscita, è necessaria al fine di evitare di creare file relativi a thread che non invochino neppure un metodo e quindi per limitare la generazione delle tracce e facilitare l’attività successiva di lettura e analisi.
Il file XML rappresentato in Figura 8.3 è relativo alle chiamate in main.Ma- in di Clienti. E’ possibile osservare le invocazioni al thread 442 che si ri- ferisce a una chiamata remota sul package grossisti di Servizi. Il thread 774 si riferisce invece a un’istanza della classe clientela.Cliente create sempre in main.Main (in realtà, il file xml riportato in Figura 8.3 è stato semplificato per esigenze di spazio).
Il ritorno dalle invocazioni delle chiamate remote viene tracciato per mez- zo della notifica dell’avvio di un thread specifico denominato DestroyJavaVM, la cui traccia è raffigurata in Figura 8.4. Un thread di questo tipo è neces- sario ogni volta che si richiede di liberare le risorse occupate e, nel caso di EXaM, viene avviato al ritorno di una chiamata remota, gestita come una connessione TCP verso l’host che esporta i servizi.
E’ per mezzo di questa notazione che EXaM ha notifica del ritorno del thread che ha avviato la chiamata remota e può tracciare l’andamento del-
Figura 8.5: Un sequence diagram raffigurante la ricostruzione dell’invocazio- ne delle chiamate remote
le chiamate sul singolo componente, verificando anche le coordinazioni tra i thread, importante dal punto di vista architetturale (vedi Figura 8.5). EXaM delega poi ad altri strumenti l’analisi del rispetto della proprietà della coordinazione tra chiamate, limitandosi a tracciarle nell’ordine in cui esse avvengono fornendo comunque un valido supporto.
In Figura 8.6 osserviamo invece l’avvio, in seguito a richiesta, delle chia- mate remote nel package grossisti dell’applicazioni Servizi e il modo in cui EXaM riesca a rilevare la classe e il metodo invocati e il tipo restituito, anche nel caso non sia un tipo primitivo ma un oggetto serializzabile scam- biato tra le due applicazioni remote, come nel caso di datiSupporto.Dati- Interface[]. Da notare anche il rilevamento dell’host che ha invocato la funzione remota nel nome stesso del thread (RMI TCP Connection(5) - 146.48.84.135).
Attraverso l’analisi dei file XML generati da EXaM, è dunque possibile studiare la sequenza di invocazioni tra i thread dei package monitorati, evi- denziando proprietà architetturali di coordinazione e sincronizzazione tra le chiamate. In Figura 8.7 è possibile osservare la sequenza di chiamate tra i
Figura 8.6: L’avvio di una chiamata remota in Servizi nella traccia del thread 720
package, ossia tra i componenti: quando un cliente richiede un servizio a un grossista, questi delega la richiesta a un commesso perché si informi sulle pro- poste di un servizio offerto dai fornitori. Le proposte vengono poi inoltrate ai clienti i quali ne scelgono una e si informano con il grossista sull’identità del fornitore, in modo da rivolgersi direttamente a lui. Tutte le invocazioni che riguardano un cliente avvengono in remoto attraverso Java RMI.
In un altro file, chiamato threadxxx_values.xml, in cui xxx è un numero che identifica univocamente il thread, vengono memorizzati i valori di tutte le variabili sullo StackFrame del thread. Si è scelto di visualizzare il valore che le variabili assumono all’ingresso del metodo invocato, ma avremmo anche potuto generare un file analogo all’uscita da ogni metodo invocato. Essendo una tale eventuale modifica piuttosto semplice da realizzare e irrilevante ai fini dello studio presentato, il secondo file con il valore delle variabili in uscita non viene generato, ma è possibile, in una versione più rifinita del tool, parametrizzare questa funzionalità attraverso il file di configurazione.
Infine, EXaM riporta, in un file separato dal nome package.MainClass.in- fo (dove package è chiaramente il nome del package e MainClass il nome della classe contenente la funzione main) lo standard output dell’applicazio- ne, le informazioni sulla Virtual Machine ed eventuali errori nell’esecuzione dell’applicazione target. In Figura 8.8 e in Figura 8.9 riportiamo rispettiva- mente il contenuto dei file main.Main.info relativo all’esecuzione di Clienti e server.Server relativo all’esecuzione di Servizi.