Comment Feed for Channel 9 - CLR 4: Debugging and Profiling API Enhancements http://ecn.channel9.msdn.com/o9/previewImages/100/467169_100x75.jpg Channel 9 - CLR 4: Debugging and Profiling API Enhancements 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. en Wed, 22 May 2013 05:16:35 GMT Wed, 22 May 2013 05:16:35 GMT Rev9 Re: CLR 4: Debugging and Profiling API Enhancements 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

posted by Ravenex

]]> http://channel9.msdn.com/Blogs/Charles/CLR-4-Debugging-and-Profiling-Enhancements#c633790146130000000 Wed, 27 May 2009 09:50:13 GMT http://channel9.msdn.com/Blogs/Charles/CLR-4-Debugging-and-Profiling-Enhancements#c633790146130000000 Ravenex Re: CLR 4: Debugging and Profiling API Enhancements 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. 

 

posted by androidi

]]> http://channel9.msdn.com/Blogs/Charles/CLR-4-Debugging-and-Profiling-Enhancements#c633790448250000000 Wed, 27 May 2009 18:13:45 GMT http://channel9.msdn.com/Blogs/Charles/CLR-4-Debugging-and-Profiling-Enhancements#c633790448250000000 androidi Re: CLR 4: Debugging and Profiling API Enhancements 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.

posted by davbr

]]> http://channel9.msdn.com/Blogs/Charles/CLR-4-Debugging-and-Profiling-Enhancements#c633790490040000000 Wed, 27 May 2009 19:23:24 GMT http://channel9.msdn.com/Blogs/Charles/CLR-4-Debugging-and-Profiling-Enhancements#c633790490040000000 davbr Re: CLR 4: Debugging and Profiling API Enhancements 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.

posted by androidi

]]> http://channel9.msdn.com/Blogs/Charles/CLR-4-Debugging-and-Profiling-Enhancements#c633791398860000000 Thu, 28 May 2009 20:38:06 GMT http://channel9.msdn.com/Blogs/Charles/CLR-4-Debugging-and-Profiling-Enhancements#c633791398860000000 androidi