Upload
imogen-dayna-glenn
View
225
Download
0
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 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
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
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
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 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
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
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 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
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.
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
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
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