Maggior controllo sul Garbage Collector

Con 'Orcas' abbiamo introdotto anche una nuova proprietà sul Garbage Collector che può essere usata dall'applicazione per specificare in che modalità il GC deve funzionare.

La nuova proprietà è definita sulla classe GCSettings (GCSettings.LatencyMode) e può assumere 3 valori:

• GCLatencyMode.Batch: con questa modalità il GC funziona con la 'concurrent' feature Off. Questo significa che allocazioni non possono avvenire contemporaneamente ad una collection. Concurrent GC è una funzionalità già disponibile in .NET 2.0 e tipicamente usata per applicazioni server (in .NET 2.0 la proprietà può essere configurata solo usando il config file);
• GCLatencyMode.Interactive: questa modalità è concurrent GC On ed è la configurazione di default in tutte le applicazioni client di .NET 2.0;
• GCLatencyMode.LowLatency: questa è una nuova modalità introdotta con Orcas. LowLatency forza il GC in una modalità di collection di memoria estremamente conservativa: in LowLatency il GC non effettua nessuna collection completa. Lo scenario tipico di uso della modalità LowLatency è quando l'applicazione non può tollerare le pause richieste per una collection completa. Chiaramente LowLatency deve essere utilizzato solo durante le fasi critiche di esecuzione di un'applicazione che ha anche dei vincoli sul tempo di esecuzione. Durante LowLatency il working set dell'applicazione può crescere molto velocemente (il GC non esegue nessuna collection completa) e quindi è importante che sia utilizzato solo quando è strettamente necessario.

Maggiori dettagli si possono trovare sul blog di Chris Lyon.

Le novità nella Base Class Library

Tralasciando le novità più evidenti che saranno trattate in dettaglio da altri articoli in questa serie (LINQ, su tutte), vorrei focalizzare l'attenzione sulle novità incluse nelle librerie di livello più basso.

Tutte queste nuove funzionalità sono incluse nei Green Bits, per cui sono opzionali ed aggiuntive.

La lista delle novità è la seguente:

• sistema integrato nella BCL per la scoperta, il caricamento, l'isolamento e il sandboxing di add-in e che garantisce l'abilità di host e add-in di funzionare correttamente con versioni successive di ciascuno o entrambi i componenti;
• miglioramenti in ClickOnce per la distribuzione di applicazioni basate su WPF, supporto di browser alternativi e possibilità di avere rebranding nell'installazione;
• miglioramenti nel supporto dei fusi orari, inclusi i casi in cui l'inizio dell'ora legale varia;
• un nuovo ReaderWriterLockSlim con performance nettamente migliori (da 2x a 5x rispetto al ReaderWriterLock) e che ha migliori proprietà di scalability su macchine multiprocessore e multicore;
• supporto per le implementazioni crittografiche certificate FIPS degli algoritmi advanced SHA e AES in .NET. I pattern di uso di queste classi seguono quelli degli algoritmi di crittografia esistenti, rendendo molto semplice per i developer l'utilizzo immediato delle nuove classi;
• una nuova struttura per memorizzare dati temporali capace di specificare un esatto momento relativo al Tempo Universale Coordinato (UTC);
• nuovi tipi per l'I/O che espongono la funzionalità delle pipe di Windows (sia named sia unnamed);
• un'implementazione ad alte prestazioni del concetto di insieme (HashSet);
• supporto per le funzionalità crittografiche curva ellittica Diffie Hellman e firma digitale con l'algoritmo della curva ellittica;
• un trace listener che logga eventi tramite ETW (il sistema di event tracing in Windows Vista);
• un trace listener ad alte prestazioni capace di loggare XML su disco secondo lo schema degli eventi;
• supporto per il modello asincrono nelle classi Socket;
• classi per il peer-to-peer networking;
• una nuova versione nettamente migliorata di WMI.NET provider extension;
• supporto per IRI (RFC 3987) nelle classi relative agli URI.

Come potete vedere, la lista è lunga anche se la si limita a quanto di nuovo c'è nella BCL.

Nel resto di questo articolo, vorrei approfondire l'analisi di alcune di queste nuove caratteristiche che possono avere molteplici applicazioni.

Molte più informazioni sulle diverse funzionalità sono disponibili sul blog del BCL team.

Il nuovo modello integrato per gli Add-in

Tipicamente, sviluppatori di applicazioni investono nell'estensibiltà per una serie di ragioni. Una ragione comune è che i clienti hanno ciascuno delle necessità molto particolari che la sola applicazione non è in grado di soddisfare completamente out-of-the-box. A questo punto è meglio rendere l'applicazione estensibile e lasciare che il cliente possa risolvere il suo problema specifico.

Indipendentemente dalla ragione per la quale si sceglie di rendere la propria applicazione estensibile, qualunque developer che abbia provato a rendere la propria applicazione estensibile sa quanto una funzionalità apparentemente semplice sia piena di tranelli e problemi nascosti. Con .NET Framework 3.5, Microsoft introduce gli assembly System.AddIn.* per attaccare due classi di problemi che praticamente tutti coloro che hanno cercato di rendere le proprie applicazioni estensibili hanno incontrato. Convenzionalmente, chiameremo questi problemi il "Problema della versione 1" e il "Problema della v.next".

Il Problema della Versione 1 si riferisce alla serie di problemi che un developer si trova ad affrontare quando aggiunge per la prima volta estensibilità alla propria applicazione; questo include task comuni come il discovery, l'attivazione, l'isolamento e il sandboxing degli add-in. Il Problema della v.next invece si riferisce all'insieme di problemi che il developer si trova ad affrontare quando l'applicazione cambia, in particolare come assicurare che vecchi add-in scritti per la versione precedente dell'applicazione continuino a funzionare con la nuova versione dell'host, come assicurare che nuovi add-in funzionino con vecchie versioni dell'host, o perfino permettere che add-in costruiti per un certo host possano funzionare con un altro.

Il nuovo modello di add-in e l'architettura che definisce affronta tutti questi problemi, mentre le singole feature in System.Addin.* rendono la soluzione del Problema della versione 1 quasi banale.

La migliore risorsa per saperne di più è il blog del feature team, che a sua volta punta a diversi articoli che approfondiscono il tema e contiene diversi esempi di codice.

Vorrei soffermarmi di più in questo articolo sull'architettura generale e su come questa possa consentire la soluzione del Problema della v.next.

Contenuti dell'articolo

• Pagina 1
  • La struttura di .NET Framework 3.5 "Orcas"
  • Il CLR in .NET Framework 3.5 "Orcas"
• Pagina 2
  • Maggior controllo sul Garbage Collector
  • Le novità nella Base Class Library
  • Il nuovo modello integrato per gli Add-in
• Pagina 3
  • Conclusioni
  • Lo speciale completo