Re: Re: CLR 4: Debugging and Profiling API Enhancements

androidi — Thu, 28 May 2009 20:38:06 GMT

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.

Re: CLR 4: Debugging and Profiling API Enhancements

David Broman — Wed, 27 May 2009 19:23:24 GMT

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.

Re: CLR 4: Debugging and Profiling API Enhancements

androidi — Wed, 27 May 2009 18:13:45 GMT

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.

Re: CLR 4: Debugging and Profiling API Enhancements

Ravenex — Wed, 27 May 2009 09:50:13 GMT

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

Comment Feed for CLR 4: Debugging and Profiling API Enhancements (Charles on Channel 9)

Re: Re: CLR 4: Debugging and Profiling API Enhancements

Re: CLR 4: Debugging and Profiling API Enhancements

Re: CLR 4: Debugging and Profiling API Enhancements

Re: CLR 4: Debugging and Profiling API Enhancements