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

.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)
.NET 3.0
(2006)
.NET 1.0
(2002)
.NET 1.1
(2003)
.NET 2.0
(2005)
.NET 4.0
(Now!)
Reminder: the CLR is…
ASP
.net
WPF
Base Class
Libraries
JIT &
NGEN
GC
WCF
Win
Forms
Profiling &
Debugging
APIs
Security
Model
DLR
LINQ
The CLR
Exception
Handling
Loader
&
Binder
…and
more!
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 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 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
Since version 2.0 applications have run on
the same CLR and framework stack
• But only certain kinds of functionality can
be added
.NET 3.5
.NET 3.0
.NET 1.0
.NET 1.1
.NET 2.0
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 3.0
.NET 2.0
.NET 4.0
Host process (e.g., Outlook)
DEMO
CLR 2.0 and 4.0 running side-by-side
in the same process
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
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 Win32
P/Invoke is (conceptually) simple
• Add [DllImport] attribute to your native static
function definition
• Map the native types to managed types
A handy reference…
Windows
HANDLE
BYTE
SHORT
WORD
INT
UINT
LONG
BOOL
DWORD
ULONG
CHAR
LPSTR
C
void*
unsigned char
short
unsigned short
int
unsigned int
long
long
unsigned long
unsigned long
char
char*
LPCSTR
Const char*
LPWSTR wchar_t*
LPCWSTR Const wchar_t*
FLOAT
Float
DOUBLE Double
CLR
Notes
_
System..::.IntPtr
32 bits or 64 bits depending on the OS
System..::.Byte
8 bits
System..::.Int16
16 bits
System..::.UInt16
16 bits
System..::.Int32
32 bits
System..::.UInt32
32 bits
System..::.Int32
32 bits
System.Int32
32 bits
System..::.UInt32
32 bits
System..::.UInt32
32 bits
System..::.Char
Decorate with ANSI.
System..::.String
Decorate with ANSI.
or System.Text..::.StringBuilder
System..::.String
Decorate with ANSI.
or System.Text..::.StringBuilder
System..::.String
Decorate with Unicode.
or System.Text..::.StringBuilder
System..::.String
Decorate with Unicode.
or System.Text..::.StringBuilder
System..::.Single
32 bits
System..::.Double
64 bits
DEMO
P/Invoke Interop Assistant
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 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
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 languages
You can just as easily use Tuples in C# or
any other .NET language
…and pass them seamlessly to F# or Python
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
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
Tail-recursion optimization
F# is a new functional language
• Based on OCaml, which is based on ML
Tail-recursion optimization
F# is a new functional language
• Based on OCaml, which is based on ML
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
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
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-trust
Faster WPF (more hardware processing)
More WinForms controls
ASP.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
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
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
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
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 segment
Background GC happens in the background
• Foreground GCs collect the ephemeral
segment so it doesn’t fill up
Latency comparison
Raw latency in microseconds
Concurrent GC (running in v4 CLR)
Background GC
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 bugs
How 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 Exceptions
A 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
• [HandleProcessCorruptedStateExceptions]
Debugging improvements
Dump 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 improvements
Dump 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 compiletime 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 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 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]
CLR Interop team on CodePlex
http://clrinterop.codeplex.com
DevLabs (CodeContracts, Pex)
http://msdn.microsoft.com/devlabs
Great CLR blogs on MSDN
http://blogs.msdn.com/clrteam
CLR blog links to other great CLR team blogs
Where to find these slides
http://blogs.msdn.com/apardoe