È Joshua Goodman lo speaker della affollatissima sessione sulle novità nel CLR 4.0. Dopo il CLR 2.0, la 4.0 è la versione successiva (nel Framework 3.x il CLR è quello della 2.0) ed introduce numerose novità.
- Certamente la novità più importante è quella che un processo potrà far girare sia la versione 2.0 che 4.0 contemporaneamente. In pratica dei plugin che girano con una versione differente di CLR rispetto a quella dell'applicazione potranno girare con la versione di CLR desiderata. Questo evita tuta una serie di side-effect e lo speaker cita un plugin di Outlook usato internamente dagli 'executive' che era realizzato con la versione 1.1 ed aveva un bug sul multithreading. Con la versione 2.0 il runtime, essendo più veloce, ha evidenziato il bug rendendo sistematicamente impossibile il suo utilizzo. Sarà anche possibile usare file di configurazione differenti per il codice che gira con una versione differente di CLR.
- No-PIA di cui ho già parlato nel dettaglio nel post della sessione dedicata a questo tema
- Nuova classe Tuple<> che facilita linguaggio com F# e Python ma che sono comodi anche per C#
- Notifiche prima di una Garbage Collection di tipo Server in generazione 2. Questo consente di eseguire load balancing ed evitare latenza.
- Background Collection sul GC di tipo Workstation. Con la 3.5 SP1 il GC può eseguire buona parte della Garbage Collection di generazione 2 in background senza sospendere l'esecuzione del codice managed.
Con il CLR 4.0 la collection in generazione 0 e 1 può avvenire contemporaneamente a quella di generazione 2, eliminando così buona parte dei problemi di latenza. - Possibilità di eseguire attach/detach di profilatori su memoria e performance counters. Il meccanismo non è invasivo (niente registry) e usabile anche in produzione.
- È possibile ora eseguire il catch di eccezioni di bassissimo livello come la corruzione dello stato e della memoria nel processo. Utile per eseguire dei log/dump prima di abbandonare l'esecuzione del processo.
- Supporto per il debugging misto 32/64 bit.
- API per capire chi sta mantenendo un lock o chi ne è in attesa
- Code Contracts. È un nuovo sistema per validare i parametri di input e il valore di output di un metodo. Nel metodo si usa CodeContract.Requires per validare i parametri di input oppure CodeContracts.Ensures per verificare che l'output rispetti certe condizioni. La cosa interessante è che è possibile usare i CodeContract sia con dei tool di analisi statica che a runtime. Siamo di fronte a una nuova generazione di validatori.
Non ci resta che provare tutte queste belle cose nella Virtual Machine. Da quello che vedo il CLR è sempre più potente e l'incremento delle performance e la duttilità del Garbage Collector lo rendono sempre più appetibile persino per applicazioni estreme come i videogame.