Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

CLR 4: Debugging and Profiling API Enhancements

Download

Right click “Save as…”

  • High Quality WMV (PC)
  • MP3 (Audio only)
  • MP4 (iPhone, Android)
  • Mid Quality WMV (Lo-band, Mobile)
  • WMV (WMV Video)
Developers Thomas Lai and David Broman join Program Manager Jon Langdon to share with us some of the new debugging and profiling enhancements in CLR 4. They've done a lot work in the upcoming release and besides evolving debugging and profilining capabilities and semantics (APIs), they've implemented (or fixed) many things customers have been asking for.

The managed debugging and profiling story with CLR 4 is based on a new core architecture (they are moving to an out of process model which means you'll be able to debug multiple threads rather than being stuck to the same thread(s) attached to the main context. Something like that. Watch, listen, learn.).

Tune in to learn about some of the design decisions made to support moving out-of-proc, improving debugger and profiling reliability, enhanced core APIs, future directions and meet some of the people who design and implement these important engineering components for the managed (.NET) world.

Enjoy.

Tags:

Follow the Discussion

  • Hey Charles,

    I guess when you were arguing on IL with Lars at Lang.NET 2009, what Lars was saying about "not necessary to have IL", he wasn't talking generally on IL on all VMs, but rather focused on JavaScript: JavaScript has one and only one wire format, and that is the source code. By the spec, JavaScript programs are only defined with source code, and when you distribute JavaScript programs, you distribute in source form. Every compatible JavaScript implementation should spit out the source code of some function when you call toString() on the function object. So the ability to deal with source code is a must-have in every JavaScript implementation. Within the VM itself, it can use whatever internal representation of the program as it likes, and some uses bytecodes, just as MSIL does. What's different is that MSIL is the wire format for .NET programs, and those bytecodes in JavaScript VMs aren't.

    When you distribute managed programs, the CLR verifies MSIL to make sure it's valid (in some environment settings you're not allowed to run unverifiable code). This is important because otherwise no one can guarantee that the program in MSIL is what is was in C# or VB, or any other source form -- some bad guy could have just made up rouge programs directly in MSIL.

    If JavaScript had IL as a wire format, then any JavaScript VM will have to do the same verifications as the CLR does, to make sure that the IL is valid. And remember JavaScript already has source form as its wire format. So whenever a JavaScript receives source code to run, it has to parse the source code and do some checking before generating IL (check No.1), and then before executing the IL it checks again (check No.2). That what Lars was saying about "you'll have to check twice if you had IL (as a wire format for JavaScript)".

    So it's not that IL is bad in general sense, it just doesn't fit into the JavaScript model of wire format, and that's it.

    I read about this in a blog, here: http://rednaxelafx.javaeye.com/blog/382429, it actually gives an example of what happens if a language has IL as one of its wire formats, but doesn't do verification on the IL before executing (in that post the example is CPython). It's in Chinese, but maybe we could get him translate it into English sometime later...

    Cheers,

    Raven

  • Should the profiler work in instrumenting mode in 2010 Beta 1? I guess I should read the rel notes since it just crashes here on simple WinForm app. 

     

  • Are you asking about the underlying CLR Profiling API, or a particular profiler you're trying to use?  (If so, which one?)  The underlying CLR Profiling API does still allow IL rewriting in beta 1 as it did in CLR 2.

  • edit sorry. I should've looked at the readme for this.. I'll try again after install of the team explorer, this below could be the cause.

    2.4.10.1 Visual Studio Team System Profiler components do not work if Team Explorer is not also installed

    To work correctly, the Visual Studio Team System Profiler requires some Team Explorer components to be installed.  Although these components are installed together with VSTS, the problem is limited to custom installations that include the Team System Profiler but exclude Team Explorer.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.