72
.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…

Embed Size (px)

DESCRIPTION

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

Citation preview

.NET Framework 4.0 CLRWorking 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 DLRASP

.net WCF LINQ …and more!

Base Class Libraries

JIT & NGE

NGC

Security

Model

Exception

Handling

Loader &

Binder

Profiling & Debugging

APIsThe CLR

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

OutlineWorking 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

OutlineWorking 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

DEMOCLR 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 typesTLBImp doesn’t have complete

information• Download shared-source version and

modify it for your code’s typesNo 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 CLRNotes _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

DEMOP/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 IntegersBig 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

TuplesBoth 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 executionFirst a bit of a digression…• Notable 3.5 SP1 performance

improvements• Faster installation, faster startup

Faster parallel code• Threadpool changes for Parallel

FrameworksHide 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 ProfileNo 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 parallelLayout optimization• Framework binaries load faster

Layout optimizationNGen creates native images on the

user’s machine• We’ve always installed native

framework binaries in the GACFor 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 codeParallel 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 codeParallel Frameworks make it easy to take advantage of multicore• Parallel Fx APIs do the threading code for you• CLR threadpool makes it scale

Garbage CollectionFirst, think of the GC as enabling

allocationsGarbage Collector Free Memory

Provider

Garbage CollectionGarbage collector allocations are fast

because they do segmented allocation• The GC gets a bunch of memory from the

OS and allocates it for youGarbage 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 GCThe 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 hereLarge 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 hereLarge 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

DEMORegister for notification of full GC

Background GCCLR 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 GCCLR 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 comparisonConcurrent GC (running in v4 CLR)

Background GC

Raw

late

ncy

in

mic

rose

cond

s

Summary: v4 is faster3.5 SP1 installs faster and starts up

faster• Client profile helps ensure that your

customers have 3.5 SP1 on their machinesFaster parallel code• With or without the Parallel Framework

APIsGarbage collector latencies are hidden• Servers and interactive applications

benefit

Fewer bugsHow we help you eliminate your bugs

Fewer bugsAppDomain Resource Monitoring• Visibility into runaway client code

Corrupted State Exceptions• Making a common bad pattern less

harmfulManaged 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

SecuritySecurity 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.

DEMODump 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 ContractsAnalysis and verification service at

compile-time and (debug) runtimeProvides 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 exampleContracts consist of preconditions,

postconditions and object invariants

Contracts exampleContracts consist of preconditions,

postconditions and object invariants

Contracts exampleContracts consist of preconditions,

postconditions and object invariants

Summary: fewer bugsCLR 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

Faster3.5 SP1 improvements• Faster installation, faster startup

Faster parallel code• Threadpool changes for Parallel

FrameworksHide garbage collector latency• Full-generation collections will be

less noticeable on servers and clients

With fewer bugsAppDomain Resource Monitoring• Visibility into runaway client code

Corrupted State Exceptions• Making a common bad pattern less

harmfulManaged 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