.NET Framework 4.0 CLR

1. .NET Framework 4.0 CLR Working better together, faster, with fewer bugs. • Andrew Pardoe, Common Language Runtime PM

2. What’s special about v4? • CLR 4.0 is the first new full stack since 2.0 • 3.0 adds WPF, WCF, WF and CardSpace • 3.5 adds LINQ, language features & more .NET 3.5 (2007) .NET 3.0 (2006) .NET 4.0 (Now!) .NET 2.0 (2005) .NET 1.1 (2003) .NET 1.0 (2002)

3. Reminder: the CLR is… ASP .net WPF WCF Win Forms DLR LINQ …and more! Base Class Libraries Profiling & Debugging APIs The CLR JIT & NGEN GC Security Model Exception Handling Loader & Binder

4. Outline • Working better together • Running two CLRs together in one process • Native and managed interop • Working better with managed languages

5. Outline • Working better together • Running two CLRs together in one process • Native and managed interop • Working better with managed languages • Faster • 3.5 SP1 performance improvements • Performance features in the core engine

6. Outline • Working better together • Running two CLRs together in one process • Native and managed interop • Working better with managed languages • Faster • 3.5 SP1 performance improvements • Performance features in the core engine • With fewer bugs • Security, correctness and monitoring • Debugging and code contracts

7. Working better together …with ourselves, with interop, and with managed languages

8. Working better together • In-process side-by-side • The CLR engine working better with itself • No PIAs • Working better with COM • P/Invoke Interop Assistant • Working better with Win32 • New support for managed languages • Features for dynamic and functionallanguages help them work together

9. Why is compatibility hard? • .NET 1.1 was highly compatible with 1.0 • But this code broke when 1.1 was installed • The code was from an Outlook add-in • An add-in used by all the executives… • -

10. Why is compatibility hard? • .NET 1.1 was highly compatible with 1.0 • But this code broke when 1.1 was installed • The code was from an Outlook add-in • An add-in used by all the executives… • -

11. No roll-forward • Since version 2.0 applications have run on the same CLR and framework stack • But only certain kinds of functionality can be added .NET 1.0 .NET 3.5 .NET 3.0 .NET 2.0 .NET 1.1

12. In-process side-by-side • Run both the old and new framework stacks in a single process • Managed add-ins work better together 2.0 add-in 3.5 add-in 4.0 add-in 4.0 add-in .NET 3.5 .NET 4.0 .NET 3.0 .NET 2.0 Host process (e.g., Outlook)

13. DEMO CLR 2.0 and 4.0 running side-by-sidein the same process

14. Working better with COM • TLBImp reads COM type library definitions & generates a managed interop assembly • May need to modify the MSIL and reassemble • Designate this as a PrimaryInteropAssembly • Every add-in needs to distribute the PIA • Any change to a PIA changes the version • Make sure add-ins use the new PIA • Create a Publisher Policy and install it in the GAC

15. It’s all about the types • TLBImp doesn’t have complete information • Download shared-source version and modify it for your code’s types • No PIAs for new interop projects • Consume referenced types at compile time • Compiler pulls in only referenced types • [TypeIdentity] attribute • Arbitrary string (or GUID) marks types as equivalent

16. Working better with Win32 • P/Invoke is (conceptually) simple • Add [DllImport] attribute to your native static function definition • Map the native types to managed types

17. A handy reference… • Windows C CLR Notes _ • HANDLEvoid* System..::.IntPtr 32 bits or 64 bits depending on the OS • BYTEunsigned char System..::.Byte 8 bits • SHORTshort System..::.Int16 16 bits • WORDunsigned short System..::.UInt16 16 bits • INTint System..::.Int32 32 bits • UINTunsigned int System..::.UInt32 32 bits • LONGlong System..::.Int32 32 bits • BOOLlong System.Int32 32 bits • DWORDunsigned long System..::.UInt32 32 bits • ULONGunsigned long System..::.UInt32 32 bits • CHARchar System..::.Char Decorate with ANSI. • LPSTRchar* System..::.String Decorate with ANSI. or System.Text..::.StringBuilder • LPCSTRConst char* System..::.String Decorate with ANSI. or System.Text..::.StringBuilder • LPWSTRwchar_t* System..::.String Decorate with Unicode. • or System.Text..::.StringBuilder • LPCWSTRConst wchar_t* System..::.String Decorate with Unicode. • or System.Text..::.StringBuilder • FLOATFloat System..::.Single 32 bits • DOUBLEDouble System..::.Double 64 bits

18. DEMO P/Invoke Interop Assistant

19. New language support • The Common Language Runtime had 16 languages when it launched • Mostly imperative and statically compiled • .NET 4.0 adds F# and dynamic languages such as Python and Ruby

20. New language support • The Common Language Runtime had 16 languages when it launched • Mostly imperative and statically compiled • .NET 4.0 adds F# and dynamic languages such as Python and Ruby • New features to support new languages • BigInteger • Tuples • Tail recursion optimizations

21. Big Integers Big integer values were a common request from both F# and dynamic languages Optima team (Microsoft Solver Foundation) helped us to design high-performance big integers

22. Tuples • Both F# and Python use tuples as first-class constructs in their language • Example: (42, “Hello world!”) • Providing a common implementation in the BCL ensures interoperability • Some complications, such as (NaN == NaN) is false

23. Common to all languages You can just as easily use Tuples in C# or any other .NET language…and pass them seamlessly to F# or Python

24. Common to all languages You can just as easily use Tuples in C# or any other .NET language…and pass them seamlessly to F# or Python

25. Common to all languages You can just as easily use Tuples in C# or any other .NET language…and pass them seamlessly to F# or Python

26. Tail-recursion optimization • F# is a new functional language • Based on OCaml, which is based on ML

27. Tail-recursion optimization • F# is a new functional language • Based on OCaml, which is based on ML

28. Summary: language support • Original promise of the CLR was support of diverse set of languages • 16 languages at launch • New languages prove the power and extensibility of the platform • New features pushed back into the platform to benefit all languages

29. Working better together • In-proc side-by-side makes the CLR work better with itself • New features without roll-forward • COM interop works better with No PIAs …and the shared-source TLBImp on CodePlex • Native interop is easier with the P/Invoke Interop Assistant on CodePlex • Language support in the BCL helps languages work together

30. Faster … and faster and faster and faster and …

31. Faster execution • First a bit of a digression… • Notable 3.5 SP1 performance improvements • Faster installation, faster startup • Faster parallel code • Threadpool changes for Parallel Frameworks • Hide garbage collector latency • Full-generation collections will beless noticeable on servers and clients

32. .NET 3.5 SP1 (because you care) • 3.5 SP1 has a lot of good stuff in it • Client profile means no install • Layout optimizations for framework assemblies means faster startup

33. .NET 3.5 SP1 (because you care) • 3.5 SP1 has a lot of good stuff in it • Client profile for easier installs • Layout optimizations for faster startup • Other stuff …we’ll get there a minute

34. Client Profile • No install on machines with 2.0 or above • Delivered through Windows Update • Vista shipped with .NET 3.0 • XP machines with 2.0 also get upgraded • Small install for machines without 2.0 • 200 KB bootstrapper, 25 MB installer • Customizable, branded 3-click install • Downloads and NGens in parallel • Layout optimization • Framework binaries load faster

35. Layout optimization • NGen creates native images on the user’s machine • We’ve always installed native framework binaries in the GAC • For 3.5 SP1 we profiled framework startup and changed layout of native images to streamline loading • Framework binaries load faster

36. .NET 3.5 SP1 (back to this) • 3.5 SP1 has a lot of good stuff in it • Client profile for easier installs • Layout optimizations for faster startup • Run from the network in full-trust • Faster WPF (more hardware processing) • More WinForms controls • ASP.net improvements • …and much, much more

37. Faster parallel code Parallel Frameworks make it easy to take advantage of multicore • Parallel Fx APIs do the threading code for you • CLR threadpool makes it scale

38. Faster parallel code Parallel Frameworks make it easy to take advantage of multicore • Parallel Fx APIs do the threading code for you • CLR threadpool makes it scale

39. Garbage Collection • First, think of the GC as enabling allocations • Garbage Collector  Free Memory Provider

40. Garbage Collection • Garbage collector allocations are fast because they do segmented allocation • The GC gets a bunch of memory from the OS and allocates it for you • Garbage collector frees can be slower because you don’t release memory directly through a single pointer • The GC needs to determine what memory is still in use

41. Generational GC • The CLR GC is generational • Newly-allocated memory is inspected more frequently than long-lived memory • Most collections collect early generations • Full collections collect all generations • And the Large Object Heap

42. Segments & Generations Ephemeral segment: young generations live here Other segments: oldest generation lives here Large Object Heap (objects > 85 000 bytes)

43. Segments & Generations Ephemeral segment: young generations live here Other segments: oldest generation lives here Large Object Heap (objects > 85 000 bytes) • Full collections can be noticeable when oldest generation and large object heap get big • GC needs to pause all managed threads • CLR v4 hides the latency from the user • Server uses Full GC Notifications • Interactive uses Background GC

44. Balance load across servers • Many large server installations balance incoming requests across identical servers Request Request Request Request Request Load balancer Server Server Server Server Server Server

45. Balance load across servers • Many large server installations balance incoming requests across identical servers Request Request Request Request Request Load balancer Server Server Server Server Server

46. DEMO Register for notification of full GC

47. Background GC • CLR defaults to “concurrent workstation GC” • Optimized for interactive applications • Concurrent GC does most of a full collection without pausing managed threads • Allocations continue on ephemeral segment • …until the ephemeral segment is full

48. Background GC • CLR defaults to “concurrent workstation GC” • Optimized for interactive applications • Concurrent GC does most of a full collection without pausing managed threads • Allocations continue on ephemeral segment • Background GC happens in the background • Foreground GCs collect the ephemeral segment so it doesn’t fill up

49. Latency comparison • Concurrent GC (running in v4 CLR) • Raw latency in microseconds • Background GC

50. Summary: v4 is faster • 3.5 SP1 installs faster and starts up faster • Client profile helps ensure that your customers have 3.5 SP1 on their machines • Faster parallel code • With or without the Parallel Framework APIs • Garbage collector latencies are hidden • Servers and interactive applications benefit