Echidna come surrogato di una Java VM condivisa
|
Introduzione
| Pare proprio che una Java VM condivisa, sebbene continuamente richiesta da sviluppatori e utenti, non sia una priorità. Promessa più volte, mai rilasciata. Si potrebbe discutere per eoni sulla sua reale utilità, esistono differenti scuole di pensiero al riguardo, comunque sarebbe almeno comodo poter lanciare più "programmi" all'interno di una stessa JVM, intendo dire "nativamente".Si, perchè da sempre esistono altri metodi per fare ciò con le VM esistenti, sebbene parziali, anche se privi di molte delle caratteristiche che ci si aspetterebbe da una VM realmente condivisa.
| Non c'e' nulla di nuovo in tutto ciò. Quando compiliamo un progetto da dentro un IDE, probabilmente stiamo chiamando il metodo main della classe javac all'interno di una VM già attiva, e la differenza(in termini di velocità) è evidente.
Tra i vari progetti votati all'emulazione di una vm condivisa, sono sempre stato affascinato dal Progetto Echidna di Javagroup (sembra che il sito non esista più, ma potete scaricarne una copia qui).
Con Echidna è possibile caricare classi e chiamare il loro metodo main con classpath e classloader proprio; in questo modo si possono lanciare più programmi Java dentro un'unica JVM.
Usando come base Echidna, qui in beanizer abbiamo sviluppato JDEngine(anche detto JDE o Java Desktop Engine), un motore/servizio open source, liberamente utilizzabile che permette di utilizzare in modo semplice le caratteristiche offerte da Echidna.
Ma torniamo proprio ad Echidna. L'approccio è semplice. Per creare un processo all'interno di una jvm attiva viene creato un nuovo classloader, le classi/librerie richieste gli vengono passate e viene lanciato il metodo main della classe eseguibile. Non troppo complicato, dopo tutto la nostra jvm è multi-threading. Vedremo tra poco i problemi/svantaggi di questo approccio. Per ora possiamo goderci la nostra vm lanciando tutti quei piccoli programmi di utilità dai quali siamo dipendenti senza la necessità di aspettare la partenza di una nuova vm e risparmiando parecchia memoria.
Vantaggi
Evitare di lanciare una java vm per ogni singolo minuscolo programma porta principalmente due vantaggi:
- Ridotto tempo di partenza, viene risparmiato tutto il tempo necessario alla partenza della vm
- Ridotto consumo di memoria, la memoria di solito allocata dalla JVM viene occupata solo una volta
Entrambi i punti sono importanti. E' vero che i processori sono sempre più potenti e che la ram costa sempre meno, ma a tuttoggi le lamentele più frequente sui programmi java sono : "Ci mette troppo a partire" e "Usa troppa memoria per piccoli programmi". E personalmente, utilizzando molti piccoli programmi java preziosissimi, adoro l'approccio della vm pseudo-condivisa, particolarmente per quegli applicativi che durante una sessione di lavoro devo lanciare più volte.
Svantaggi
Stiamo solo emulando una macchina virtuale java condivisa, e questo pone alcune limitazioni. Prima di tutto, se un processo impazzisce è probabile che il danno si propaghi all'intera vm con gli altri processi attivi al suo interno. Secondo, sebbene vengano usati differenti classloader per i nostri processi, non esiste una reale segregazione degli stessi e questo potrebbe causare problemi di sicurezza. Terzo, il thread di eventi awt è unico per vm. Tralasciando di spiegare tutte le implicazioni di questo, significa che ad esempio se uno dei processi intra-vm apre una finestra modale, questa sarà modale per l'intera vm. Quarto, la maggior parte dei programmi termina con un System.exit, che cerca di uccidere la vm. Possiamo intercettarlo, ma a volte questo crea qualche problema. Altre limitazioni sono legate a quei programmi che usino propri classloader, spesso incompatibili con la nostra vm pseudo-condivisa, e così via.
Quando utilizzarla
Avendo ben presenti le problematiche esposte, c'è spazio per una vm pseudo-condivisa?
Forse si, principalmente per quanto esposto nella sezione "Vantaggi". Di solito, piccole utilità e programmi di piccole/medie dimensioni funzioneranno tranquillamente all'interno di una singola JVM, se non utilizzano classloader esotici o altri trucchi stravaganti.
Hasta la proxima.
|
Articoli 
