Slim Binaries

Gianmaria Pedrini Paolo Gianrossi

20 febbraio 2003
 Cosa sono?
• Una forma di file oggetto binario multi-piattaforma
basato su rappresentazioni intermedie dei pro-
grammi tramite alberi semantici, ed in quanto
tale, alternativo sia al bytecode, sia ai “FAT” bi-
naries.

Inciso: “Fat” Binaries‘

• Un eseguibile che possa contenere più versioni del-
lo stesso programma nei codici macchina di diverse
architetture.

• Da eseguibili di questo genere il sistema operativo può

distinguere e mandare in esecuzione “al volo” la ver-
sione più appropriata per l’architettura utilizzata.

• Essendo necessaria la presenza di una versione del

codice per ogni architettura supportata, la dimensio-
ne del file tende ad aumentare con inusitata facilita‘.
 L’approccio “Slim” e quello “FAT” non sono neces-
sariamente in contrasto.
 Struttura
Uno Slim Binary consta fondamentalmente di due par-
ti:

• una symbol table,

• un albero sintattico compresso.
 Il compito del compilatore

• In questo caso non la generazione di codice mac-

china.
• Nemmeno quello di una simulazione di codice
macchina.
• Il compilatore effettua le fasi di parsing e scan-
ning, come di norma.
E come al solito è durante queste fasi che si iden-
tificano errori di sintassi e di tipo.
• Ritrovandosi ad aver generato un albero sintatti-
co rappresentante il programma, il compilatore
si appresta a comprimere e serializzare l’albero
con un algoritmo dichiaratamente di ispirazione
LZW.
La scelta di questo tipo di compressione deriva dal-
l’osservazione che non di rado parti diverse di un pro-
gramma si rivelano essere molto simili. La compressio-
ne in questione utilizza un dizionario, che al termine
dell’esecuzione viene gettato. Verrà rigenerato dal
compilatore all’atto dell’esecuzione.
 Prestazioni degli Slim Binaries

• Portabilità
• Efficienza
• Dimensioni
Prestazioni degli Slim Binaries (cont.)

• Il paragone principale è con Java.

• Speedup rispetto a Java interpretato: 10.05 in
media
• Speedup massimo con operazioni su Bitfield (20.82)
e Compressione di Huffman (20.68).
Prestazioni degli Slim Binaries (cont.)

• Rispetto a codice C++ ottimizzato, tre volte e mez-

zo più lento.
• Il vero collo di bottiglia è però la rete!
Prestazioni degli Slim Binaries :(cont.)

• Su applicazioni in rete: il tempo di download di-

venta significativo
• Dimensioni: quasi un quarto del codice sorgen-
te, quasi un terzo di un binario per i386.
 Ottimizzazioni

• Compressione
• Ottimizzazioni a compile-time
• Ottimizzazioni a load-time
• Ottimizzazioni a run-time
 Compressione

• Slim binary = Symbol Table + AST (Abstract Syntax

Tree), compresso con Huffman modificato
• Idea: alcune istruzioni (es. j++;) sono sempre le
stesse in punti diversi del programma.
• Si usa un dizionario dinamico.
 Compressione (cont.)

• Il dizionario è inizialmente minimale.

• Viene aggiornato dinamicamente

• Sono note le regole di scoping

=⇒ è possibile ottimizzare l’algoritmo in modo

importante
=⇒ La compressione ottenuta è molto alta.
 Ottimizzazioni a Load-Time

• È possibile ottimizzare per ogni architettura a load

time
• L’AST (Abstract Syntax Tree) possiede tutta l’infor-
mazione richiesta per ottimizzare
• Cio non vale per un bytecode.
• Gli Slim Binaries hanno quindi un vantaggio su
Java.
 Ottimizzazioni a Run-Time

• All’avvio del programma, viene generato velo-

cemente un binario non ottimizzato.
• Vengono usati i cicli idle della CPU per rigenera-
re codice sempre piu’ ottimizzato
• Rispetto ai compilatori ad ottimizzazione aggres-
siva, c’è il vantaggio di conoscere la situazione
reale del programma: non è un’ottimizzazione
euristica.
Ottimizzazioni a Run-Time (cont.)

• Due strumenti a disposizione:

– Real Time Optimizer

– Profiler
• Il Realtime Optimizer è un processo in background che
genera codice sempre più ottimizzato basandosi sui
dati del profiler.

• Il Profiler analizza a run time l’instruction flow del pro-

gramma e fornisce dati reali al run time optimizer.
 Le applicazioni

• Esiste un Plug-In per Netscape Navigator che im-

plementa questa architettura (Juice)
• Anche senza ottimizzazioni Run Time: Speedup
tra 12 e 18 su operazioni elementari (somme, ecc.)
rispetto a Interpreted Java Byte Code su IE 3.0
(Pentium 166MHz)
 Le applicazioni (cont.)

• In sistemi embedded, è da preferirsi comunque

un architettura “java-like” a causa della ridotta
potenza di calcolo di questi sistemi.
 Conclusioni

• Gli Slim Binaries garantiscono portabilità senza

inficiare l’efficienza dell’esecuzione,
• le prestazioni li rendono paragonabili al codice
sorgente compilato nativamente,
• secondo Franz, non è da escludere a priori la
possibile migrazione da codice nativo a Slim Bi-
naries anche per applicazioni “normali”.
Bibliografia

[1] Thomas Kistler, Michael Franz; A Tree-Based

Alternative to Java Byte-Codes.
[2] Michael Franz, Thomas Kistler: Slim Binaries,
1996.