Modularit

1
Modularità e Compilazione Separata

• Mauro Franceschi, Giacomo Zanghi

2
Concetti Generali

• La compilazione separata permette un completo
  controllo della coerenza tra le entità condivisi
  tra i moduli (come già visto a lezione).
• La coerenza non può essere garantita solamente
  dal compilatore ma necessita anche di adeguati
  concetti e costrutti nel linguaggio (es. moduli).

3
Concetti Generali

• Come può il compilatore garantire che gli oggetti
  visibili al di fuori dei confini del modulo siano
  usati in modo conforme con le regole di
  compatibilità?
• O meglio
• come possono essere visibili le dichiarazioni di
  un modulo durante la compilazione di un altro
  modulo?
• Soluzione una symbol table per le entità
  esterne, memorizzabile in modo che sia
  disponibile per diverse compilazioni
• Il compilatore ripristina la symbol table dal
  symbol file ogni qualvolta linterfaccia
  compare nella import list del modulo che si sta
  compilando.

4
Moduli

• Abbiamo già visto nella nostra carriera a cosa
  servono i moduli
• Abbiamo visto a lezione i moduli in Modula-2 i
  concetti di definition module (module
  interface) ed import list
• Ora vediamo come sono implementati i moduli in
  Oberon.

5
Oberon

• Le parti di definition ed implementation sono
  fuse in una sola
• Le entità che devono essere esportate per creare
  linterfaccia sono segnati con un asterisco
  nella loro dichiarazione
• Vantaggi
• - in Oberon basta una sola compilazione
• - non bisogna gestire due file separati.

6
Moduli in Oberon
7
IL Problema della Consistenza

• Concetti Generali
• I client di unentità esportata hanno bisogno di
  informazioni per utilizzarla (memorizzate nel
  symbol file). Questi client devono essere
  invalidati quando queste informazioni vengono
  modificate!
• Per ripristinare lintegrità bisogna ricompilare.

8
Cosa succede?
Nei moderni linguaggi di alto livello le
compilazioni ridondanti sono un pericolo serio.
Il costo del processo di aggiunta di poche
dichiarazioni o modifiche minori può essere così
grave da ritardare la crescita e levoluzione del
sistema stesso.
9
Quindi

• Lestensione di uninterfaccia con nuovi oggetti
  deve lasciare le informazioni delle entità già
  esistenti che non sono cambiate, in modo che i
  client di queste vecchie entità non necessitino
  di essere ricompilati

10
Ma più che altro
Oggigiorno i sistemi sono composti di librerie di
moduli che, in futuro, verranno utilizzati per
lo sviluppo di nuove applicazioni. Inoltre non
dovrebbe mai essere necessaria la ricompilazione
di un sistema solo perché viene utilizzata una
nuova versione di una libreria.
11
Obiettivo
Permettere lestensione dei moduli evitando
inutili ricompilazioni e continuando a garantire
la consistenza tra i moduli.
O meglio eliminare il problema alla radice
evitando linvalidazione dei client.
12
La Consistenza in Oberon
In Oberon il modello originale prevede una key
nel symbol file che viene rigenerata ad ogni
compilazione.

• Ora vedremo altri due modelli migliorati
• Layer Model
• Object Model.

13
IL Layer Model di OP2

• Lo Stack degli Extension Layers
• La parte dei symbol file esistenti, deve rimanere
  immutata da unestensione dellinterfaccia. Ogni
  volta che uninterfaccia viene estesa , un nuovo
  livello di estensione appare al top
  dellinterfaccia esistente.
• Estensioni portano a Interfaccia Multilivello --gt
  Stack di livelli ordinati.
• Non è possibile determinare il livello a cui un
  oggetto appartiene, ma solo guardare se la
  dichiarazione e nel testo sorgente(tramite il
  vecchio symbol file).
• Tabella in memoria che associa un numero di
  livello per ogni nome presente nel symbol file.
• Il Numero di Livello di ogni oggetto ? Posizione
  delloggetto nel symbol file.

14
IL Layer Model di OP2
Routine di compilazione
15
IL Layer Model di OP2

• Controllo sulla Consistenza
• Client di un modulo vede stack di livelli che
  descrivono linterfaccia importata.
• Se linterfaccia venisse estesa nello stesso
  tempo, la consistenza sarebbe garantita, perché
  lo stack di livelli, richiesto dal client, è
  presente come un prefisso dello stack
  effettivamente fornito.
• Il Client per ogni modulo importato specifica nel
  suo object file il numero di livelli che
  necessita così come il fingerprint.
• Il modulo che esporta elenca un fingerprint per
  ogni livello di strato, allora un client può
  importare un certo numero di livelli.

16
IL Layer Model di OP2

• Controllo sulla Consistenza
• Fingerprint è una funzione di hash sul contenuto
  dei livelli.
• Per trovare il Fingerprint di un livello ci si
  basa anche sul Fingerprint del livello
  precedente.
• Vantaggi i livelli hanno sempre un solo id
  indipendente dal lavoro a compilation time.
• La funzione di Fingerprinting garantisce che I
  cambiamenti su un certo livello si ripercuotono
  sul suo fingerprint.

17
IL Layer Model di OP2

• Esempio controllo della consistenza

18
Object Model premesse

• Evitare di mantenere la cronologia dello
  sviluppo
• Prevenire disastrose conseguenze dovute alla
  perdita di symbol file
• Consistency checking con una granularità più fine.

19
Object Model l idea

• Il problema è distinguere I nuovi oggetti
  introdotti con lespansione del modulo
• Considera laltro estremo rispetto al modello
  classico e al Layer Model un layer ed un
  identificativo individuale (fingerprint) per ogni
  oggetto
• Cambia laspetto della lista degli oggetti
  importati, serve la coppia (objname, fingerprint).

20
Esempio della lista di esportazione
Passo 2
Passo 1
21
Object Model Fingerprinting

• Nel layer model la funzione di fingerprinting era
  una funzione di hashing qui non si può
• Che cosa possiamo usare e cosa no ?
• Per capirlo ricordiamoci che il fingerprint serve
  a controllare la consistenza delle entità
  esportati al di fuori dei confini di un modulo.

22
Object Model Fingerprinting
Cosa non possiamo usare
Cosa possiamo usare

• Attributi non esportati
• Indirizzi delle variabili
• Indirizzi dei descrittori di tipo

• Il suo tipo (non basta il nome)
• I suoi attributi
• Il nome delloggetto (dipende)

23
Object Model Fingerprinting

• Il fingerprint di un oggetto è generato dai
  fingerprint del suo tipo e delle sue sottoparti
  considerate
• Inoltre per le structure viene inserito anche il
  nome del modulo e il nome canonico
• I fingerprint dei tipi predefiniti sono costanti
  e predefiniti.

24
Esempio di fingerprint associati
25
Considerazioni
Ora facciamo una breve comparazione tra i tre
modelli in termini di efficienza.
Per il benchmarks verrà usato leditor grafico
Draw che è unapplicazione Oberon composta di 5
moduli per un totale di 46200 bytes.
26
Dimensione dell object file
27
Dimensione del symbol file
28
Tempo di compilazione
29
Uso della memoria
30
Conclusioni
Entrambi i modelli visti hanno raggiunto lo scopo
di poter estendere i moduli limitando le
invalidazioni.
Il miglior modello è risultato essere l object
model. Risolve il problema dellinvalidazione dei
client nel caso in cui symbol file vada perduto.
Inoltre permette leliminazione di oggetti
obsoleti senza invalidare i client che non usano
tali oggetti.
31
Bibliografia

• Separate compilation and Module Extension,
  autoreRegis Bernard Joseph Crelier.