Il vero problema non è più la RAM. Se negli anni '80 c'era chi la metteva in cassaforte (visto con i miei occhi), oggi non è più quella gran spesa e possiamo viaggiare con 2GB senza alleggerire più di tanto il portafoglio.
In molti lamentano l'occupazione di memoria eccessiva delle applicazioni ma questo è un approccio che dovremo imparare a dimenticare perché la RAM inutilizzata in un PC è solo uno spreco e il godimento del geek a vedere RAM libera non dà altri benefici.
Certo è importante che la RAM sia ben utilizzata e non sprecata, evitando per esempio di fare una select * portando tutto quanto in memoria, ignari che nel mondo disconnesso in cui viviamo i dati finiscono tutti quanti in RAM. Ma i discorsi sulla memoria meritano un futuro post e altro genere di discussioni.
La vera preoccupazione è per gli handle. Gli handle sono il modo per usare gli oggetti di Windows (si, Windows internamente ha il concetto di oggetto) di cui ne esistono di diversi tipi:
- User (Finestre, menu, icone, hook, etc.)
- GDI (Bitmap, font, Pen, Brush, Metafile, etc.)
- Kernel (Thread, Processi, Mutex, File, Eventi, Socket, Token, etc.)
Mentre per gli oggetti kernel lo spazio per gli handle è sostanzialmente illimitato perché dipende dalla memoria disponibile, GDI e User sono molto più limitati e ciascuno di questi due può essere al massimo 64K per Session e 10000 per processo (quest'ultimo è riconfigurabile via registry).
Apparentemente questi sono numeri grossi, lontani, ma provate ad aprire il task manager e aggiungere Handle, User Object e GDI Object alle colonne dei processi, e della sorpresa che troverete sui PC che lavorano sul serio ne parlerò in un altro post.
Il problema non è tutto qui. Anzi il bello (o forse dovrei dire il brutto) è che ci sono anche dei limiti per lo spazio di oggetti User e GDI utilizzabili in un desktop.
Giusto per fare un veloce ripasso sull'architettura di Windows, nell'OS (chi era al Security Roadshow dell'anno scorso si ricorderà di queste cose ... spero 
) ci sono le sessioni (la sessione 0 è tipicamente la logon locale ad un PC mentre quelle >0 sono quelle con i terminal services, ma poi anche lo User Switch su XP usa una sessione supplementare). In ciascuna sessione ci sono una o più Windows Station (di cui la Winsta0 è quella interattiva, cioè quella che appare a video) e dentro ciascuna Windows Station ci sono uno o più dekstop (di default sono tre).
In ciascun desktop c'è un limite (di default 3072KB) di heap usabile per oggetti User e GDI. Spannometricamente possiamo pensare a circa (ma è molto variabile) 200byte di desktop heap consumato per ciascun handle di tipo User o GDI.
Se siete finestre-dipendenti come il sottoscritto vi sarete accorti che a forza di fare doppio click, a un certo punto non si riesce più ad aprire nulla. Complimenti, siete arrivati al limite dello heap del desktop. La soluzione è di aumentarlo, certo, ma attenzione che la somma complessiva di tutti i desktop e ammenicoli vari non può superare i 48MB (o meglio potrebbe ma a scapito dello spazio di indirizzamento virtuale, il che lo rende sconsigliabile). Perciò il default di 3072K è bene non alzarlo in modo esagerato.
Le altre due soluzioni per abbattere il limite sono quelle di usare Vista (che ha alzato il limite) oppure una piattaforma x64.
Cosa significa tutto ciò dal punto di vista del developer?
- È bene fare buon uso degli handle perché i programmi che eccedono stanno fortemente limitando le risorse ad altre applicazioni
- Chi sviluppa con codice managed deve usare quello "stramaledetto" Dispose, soprattutto su tutti gli oggetti User e GDI.
- Chi sviluppa codice unmanaged deve guardarsi bene dai "resource leak" e chiamare sempre le varie CloseHandle, etc.
- Chi sviluppa in kernel mode (driver & C) e commette reati di "resource leak" verrà punito con fischi nelle orecchie da parte di tutti gli utenti costretti a frequenti reboot.
- Il numero di handle è anche un bizzarro indicatore di performance. Più ne usiamo, maggiore è la probabilità di transizione da User-mode a Kernel-mode che ha un costo non trascurabile.
E soprattutto:
- Non possiamo dare per scontato che quando apriamo una form, questa si apra veramente. Se l'utente sta lavorando in un desktop che è già al limite, la nostra applicazione potrebbe fallire per tutto ciò che coinvolge l'uso di oggetti User/GDI. E venirne a capo non è affatto banale.
Ma in giro ci sono dei colpevoli di eccessivo uso di handle? Si ...