1
::. Le Metriche
Metriche
Quantitative
Qualitative
•Piattaforme hw-sw che
supportano le VM.
•Ciclo di sviluppo
•Tipologia di classi
supportate
•Tipo di supporto alle
Graphical User Interface.
•Compatibilità con java.
•Impronta di memoria.
•Multithreading.
•Tempo di chiamata a
metodi.
•Overhead delle VM.
•Tempo per le operazioni
di Input/Output su file.
•Tempo per le operazioni
di Input/Output su rete.
1
::. Valutazioni quantitative
Il multithreading
• Livello di multithreading:
Jeode
Java Thread X
CrEme
Java Thread X
CrEme Task
Java Thread Y
OS Task A
RTOS
RTOS
Task A
Task B
Task C
Native Threads
Modello preemptive in cui a ciascun thread Java
corrisponde un thread del RTOS: integrazione con i thread
nativi e sinergia con lo schedulatore del S.O.
OS Task B
CrEme
Kernel
Java Thread Y
Java Thread Z
Java Thread U
Java Thread V
OS Task C
OS Task D
I thread Java unitamente alla VM, sono visti dal RTOS come un
singolo task. La schedulazione dei thread è a carico della VM. Tale
modello è detto blue thtread, poiché è non preemptive.
Per entrambe le VM: I thread ad eguale priorità sono eseguiti a turno (round-robin).I thread a priorità più bassa possono andare in
starvation
5
1
::. Valutazioni quantitative
Il multithreading
Livello di multithreading: l’algoritmo
Il thread principale compie le seguenti azioni:
•Istanzia e avvia il thread FaiQualcosa (che esegue operazioni che abbiano una certa rilevanza
temporale e calcola il tempo impiegato per farlo) per un numero fissato di volte, in modo tale da
avere più rilevazioni temporali senza che vi siano altri thread Java nel sistema.
•Istanzia e lancia un numero di thread FaiNulla (specificato da riga di comando) e determina il
tempo necessario a compiere tale azione. Tale tempo concorre a determinare lo stato di trash
del sistema.
•Istanzia e avvia il thread FaiQualcosa per un numero di volte proporzionale al numero di thread
FaiNulla, in tale modo si cerca di avere valutazioni temporali a regime.
La stima si ottiene osservando il numero di thread in
corrispondenza del quale si verifica uno dei due eventi:
•il sistema solleva una eccezione del tipo out of memory;
•il sistema innesca dinamiche di trashing.
1
::. Valutazioni quantitative
Il multithreading
Livello di multithreading: le stime
Tempi medi di esecuzione del thread FaiQualcosa
120000
100000
80000
Livello di Multithreading
Stima
Jeode
CrEme
< 400
< 1200
•CrEme solleva una eccezione del tipo out
of memory (33Mb di memoria libera);
•Jeode innesca una dinamica di trashing.
ms 60000
Jeode
CrEme
40000
20000
0
0
5
10
20
50
100
200
NThread
Al crescere del numero di thread nel sistema il bilancio è favorevole a Jeode finquando NThread si aggira intorno alla
decina. Da un certo punto in avanti, CrEme risulta avere prestazioni temporali nettamente inferiori rispetto a Jeode, il che
lascia supporre che la piattaforma CrEme abbia un tempo di cambio di contesto molto minore rispetto a quello della
piattaforma Jeode.
Per quanto riguarda gli algoritmi multithread, Jeode ha un maggiore overhead in termini di utilizzo della CPU rispetto
a CrEme la quale ha un overhead maggiore in termini di utilizzo della memoria rispetto alla prima piattaforma.
6
1
::. Valutazioni quantitative
Il multithreading
• Prestazione di un algoritmo multithread: il prodotto tra due matrici.
1000000
900000
40000
800000
35000
700000
600000
ms
30000
Jeode
500000
CrEme
400000
300000
200000
25000
ms 20000
SuperWaba
15000
Ewe
10000
5000
100000
0
20
50
100
110
145
0
150
20
50
Dimensione matrici
Dimensione matrici
I risultati confermano le ipotesi fatte nell’analisi del livello di multithreading,
in relazione all’overhead e al tempo di cambio di contesto, degli algoritmi
multithread eseguiti sulle macchine Java-compliant.
1
::. Valutazioni quantitative
Overhead delle macchine virtuali
Footprint memory
(in termini di memoria utilizzata)
4500
4000
4000
3000
CrEme
Kb 2000
SuperWaba
1000
0
3500
Jeode
Ewe
3000
Kb
2500
2000
1500
1000
500
0
Virtual Machine
Virtual Machine
7
1
::. Valutazioni quantitative
Tempi medi di scrittura su file
Jeode
CrEme
SuperWaba
Tempi medi di lettura su file
Ewe
800000
5000000
4500000
700000
4000000
600000
3500000
500000
3000000
ms 400000
ms 2500000
300000
2000000
200000
1500000
1000000
Ewe
SuperWaba
CrEme
500000
0
1 Mb
2 Mb
100000
0
Jeode
4 Mb
1 Mb
2 Mb
4 Mb
8 Mb
8 Mb
1
::. Valutazioni quantitative
Tempi medi di chiamata a metodi
Jeode
CrEme
SuperWaba
Delay delle macchine virtuali
Ewe
4,00E-03
7
3,50E-03
6
3,00E-03
5
2,50E-03
ms 2,00E-03
ms
1,50E-03
Ewe
SuperWaba
CrEme
1,00E-03
5,00E-04
Jeode
3
2
1
0
Virtual Machine
Un parametro
strutturato
Un parametro
elementare
Senza parametri
0,00E+00
4
8
1
::. Valutazioni qualitative
Disponibilità
Interfaccia utente
Jeode
CrEme
SWaba
Ewe
Jeode
WinCE/PPC
Truffle
PalmOS
AWT
Linux
Swing
CrEme
SWaba
Ewe
opt
Ciclo di sviluppo
Compatibilità con Java
•Java-compliant: analogo al ciclo di sviluppo
di un’applicazione Java.
•Java-compliant: completa.
•SuperWaba: articolato, necessita
generazione eseguibili, mediante applicazione
senza interfaccia grafica.
•Ewe: discreta
•SuperWaba: modesta.
•Ewe: meno articolato di SWaba, è opzionale
la generazione degli eseguibili, realizzata con
un’applicazione dotata di interfaccia grafica.
1
::. Valutazioni qualitative
Classi supportate
Jeode
CrEme
SWaba
Ewe
Jeode
Java.lang
SQL
Util
Applet
I/O
User Interface
Net
Game API
Zip
Accesso registri di sistema
Reflect
Visualizzazione dati GPS
Math
Protocollo Garmin GPS
trattamento dei dati
API per PPC e PalmOS
RMI
API di com. tra PC e PDA
CrEme
SWaba
Ewe
Security
9
1
::. Conclusioni
I test sperimentali eseguiti sul testbed hanno dimostrato che,
a parità di sistema operativo, non si ha uniformità di risultati
nelle prestazioni delle differenti macchine virtuali. Risulta
quindi fondamentale l’implementazione delle java virtual
machine, ma è altrettanto basilare l’ottimizzazione delle API
messe a disposizione da ciascuna piattaforma.
Non è possibile eleggere una macchina virtuale principe
in assoluto, ma è possibile discernere in termini relativi in
base ai requisiti dei dispositivi e al relativo campo di
impiego.
10
