net framework 4.0 clr
DESCRIPTION
.NET Framework 4.0 CLR. Working better together, faster, with fewer bugs. Andrew Pardoe, Common Language Runtime PM. 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). - PowerPoint PPT PresentationTRANSCRIPT
.NET Framework 4.0 CLR
Working better together, faster, with fewer bugs.
Andrew Pardoe, Common Language Runtime PM
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 1.0(2002)
.NET 1.1(2003)
.NET 2.0(2005)
.NET 4.0(Now!)
.NET 3.0(2006)
.NET 3.5(2007)
Reminder: the CLR is…
WPF Win Forms DLR
ASP .net
WCF LINQ …and more!
Base Class Libraries
JIT & NGE
NGC
Security
Model
Exception
Handling
Loader &
Binder
Profiling & Debugging
APIs
The CLR
Outline
Working better together• Running two CLRs together in one process• Native and managed interop• Working better with managed languages
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
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
Working better together…with ourselves, with interop, and with managed languages
Working better togetherIn-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 functional
languages help them work together
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…
• -
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…
• -
No roll-forward
.NET 1.0 .NET 1.1 .NET 2.0
.NET 3.0
.NET 3.5
Since version 2.0 applications have run on the same CLR and framework stack• But only certain kinds of functionality
can be added
In-process side-by-side
.NET 2.0
.NET 3.0
.NET 3.5
Run both the old and new framework stacks in a single process• Managed add-ins work better
together
.NET 4.0
Host process (e.g., Outlook)
2.0add-in
3.5add-in
4.0add-in
4.0add-in
DEMO
CLR 2.0 and 4.0 running side-by-sidein the same process
Working better with COMTLBImp 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
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
Working better with Win32P/Invoke is (conceptually) simple• Add [DllImport] attribute to your native
static function definition• Map the native types to managed types
A handy reference…
Windows C CLR Notes _HANDLE void* System..::.IntPtr 32 bits or 64 bits depending on the OS BYTE unsigned char System..::.Byte 8 bits SHORT short System..::.Int16 16 bits WORD unsigned short System..::.UInt16 16 bits INT int System..::.Int32 32 bits UINT unsigned int System..::.UInt32 32 bits LONG long System..::.Int32 32 bits BOOL long System.Int32 32 bits DWORD unsigned long System..::.UInt32 32 bits ULONG unsigned long System..::.UInt32 32 bits CHAR char System..::.Char Decorate with ANSI. LPSTR char* System..::.String Decorate with ANSI.
or System.Text..::.StringBuilderLPCSTR Const char* System..::.String Decorate with ANSI.
or System.Text..::.StringBuilderLPWSTR wchar_t* System..::.String Decorate with Unicode.
or System.Text..::.StringBuilderLPCWSTR Const wchar_t* System..::.String Decorate with Unicode.
or System.Text..::.StringBuilderFLOAT Float System..::.Single 32 bits DOUBLE Double System..::.Double64 bits
DEMO
P/Invoke Interop Assistant
New language supportThe 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 language supportThe 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
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
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
Common to all languagesYou can just as easily use Tuples in C# or any other .NET language …and pass them seamlessly to F# or Python
Common to all languagesYou can just as easily use Tuples in C# or any other .NET language …and pass them seamlessly to F# or Python
Common to all languagesYou can just as easily use Tuples in C# or any other .NET language …and pass them seamlessly to F# or Python
Tail-recursion optimizationF# is a new functional language• Based on OCaml, which is based on ML
Tail-recursion optimizationF# is a new functional language• Based on OCaml, which is based on ML
Summary: language supportOriginal 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
Working better togetherIn-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
Faster… and faster and faster and faster and …
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 be
less noticeable on servers and clients
.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
.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
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
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
.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-trustFaster WPF (more hardware
processing)More WinForms controlsASP.net improvements…and much, much more
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
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
Garbage Collection
First, think of the GC as enabling allocations
Garbage Collector Free Memory Provider
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
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
Segments & Generations
Ephemeral segment: young generations live here
Other segments: oldest generation lives here
Large Object Heap (objects > 85 000 bytes)
Segments & Generations
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
Ephemeral segment: young generations live here
Other segments: oldest generation lives here
Large Object Heap (objects > 85 000 bytes)
Balance load across serversMany large server installations
balance incoming requests across identical servers
Load balancer
Server Server Server Server Server Server
Request
Request
Request
Request
Request
Balance load across serversMany large server installations
balance incoming requests across identical servers
Load balancer
Server Server Server Server Server
Request
Request
Request
Request
Request
DEMO
Register for notification of full GC
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
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 segmentBackground GC happens in the background• Foreground GCs collect the ephemeral
segment so it doesn’t fill up
Latency comparison
Concurrent GC (running in v4 CLR)
Background GC
Raw
late
ncy in
m
icro
secon
ds
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
Fewer bugsHow we help you eliminate your bugs
Fewer bugs
AppDomain Resource Monitoring• Visibility into runaway client code
Corrupted State Exceptions• Making a common bad pattern less
harmful
Managed dump debugging…and a little surprise about x64 mixed
mode
Code contracts• Analysis and static verification
Speaking of the GC…
AppDomain Resource Monitoring uses the GC to collect data for your application• Servers often isolate client code in
AppDomains but have no insight into resource usage
• AppDomain Resource Monitoring provides insight into memory and processor usage on a per-AppDomain basis
A common bad pattern
A common bad pattern
What if Exception e is an Access Violation?
Corrupted State ExceptionsA set of exceptions indicate your
process state is corrupted• Access Violations are the most common• Does not include Out of Memory,
Division by Zero, Stack Overflow, Null Reference
Normal code will no longer see these• [HandleProcessCorruptedStateExceptio
ns]
Debugging improvementsDump debugging support • Offered through ICorDebug (same API
as live debugging support)• APIs enable dump debugging in any
managed debugger• Support for WER (Watson) minidumps in
VS
Security
Security Transparency as a first-class enforcement mechanism
• Much easier to reason about and verify the security of partial trust applications and libraries.
No Machine-Wide Code Access Security Policy
• Hosts define security decisions for hosted code.• Unhosted managed code behaves the same as
native code.
DEMO
Dump debugging
Debugging improvementsDump debugging support • Offered through ICorDebug (same API
as live debugging support)• APIs enable dump debugging in any
managed debugger• Support for WER (Watson) minidumps in
VS
(x64 mixed mode debugging works!)
Code Contracts
Analysis and verification service at compile-time and (debug) runtime
Provides you a way to tell the computer what you know about your code• E.g., this argument should never be
“null”• This function returns a non-negative
value
Contracts example
Contracts consist of preconditions, postconditions and object invariants
Contracts example
Contracts consist of preconditions, postconditions and object invariants
Contracts example
Contracts consist of preconditions, postconditions and object invariants
Summary: fewer bugs
CLR v4 helps you to find bugs in your code• AppDomain Resource Monitoring• Debugging improvements
…and helps you to not put as many bugs in your code• Corrupted State Exceptions• Code contracts
Conclusion(in three parts)
Working better togetherIn-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 functional
languages help them work together
Faster
3.5 SP1 improvements• Faster installation, faster startup
Faster parallel code• Threadpool changes for Parallel
Frameworks
Hide garbage collector latency• Full-generation collections will be
less noticeable on servers and clients
With fewer bugs
AppDomain Resource Monitoring• Visibility into runaway client code
Corrupted State Exceptions• Making a common bad pattern less
harmful
Managed dump debugging• and x64 mixed-mode debugging
Code contracts• Analysis and static verification
Questions?More questions?
mailto://[email protected] Interop team on CodePlex
http://clrinterop.codeplex.comDevLabs (CodeContracts, Pex)
http://msdn.microsoft.com/devlabsGreat CLR blogs on MSDN
http://blogs.msdn.com/clrteamCLR blog links to other great CLR team blogs
Where to find these slideshttp://blogs.msdn.com/apardoe