Jason Zander - Tour of the .NET CLR team
- Posted: Nov 17, 2004 at 8:50PM
- 34 comments
Jason Zander invited Charles Torre and cameraman Robert Scoble to meet the .NET Common Language Runtime team.
In this first of three segments (it's a big team!) you'll meet a variety of developers from across the team and see what they are working on.
Don't know what this team does? Well, the .NET CLR is at the center of all .NET applications. So, if you're writing .NET apps, you are using this team's work.
You'll meet more of the CLR team over the next week.
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.
More entries in this blog
-
Gabriel Torok - Protecting .NET applications…
-
Jason Zander - Tour of the .NET CLR team
-
Scott Garvey - Discussion of Smart Clients
Follow the discussion
Oops, something didn't work.
What does this mean?
Subscriptions allow us send you email notifications when new content is added. You need to be signed in to Channel 9 to use this feature.What does this mean?
Subscriptions allow us send you email notifications when new content is added.sign up for email notifications?
I guess this means that Windows will be more stable now? No more having to worry when I install a program if the developers of the app paid attention to their indexes? No more memory leaks?
CLR is a godsend. Still sounds a little like a JRE though.
should fire all members of the CLR team ,
and replace with the MASM team.
the garbage always makes a garbage!!!
I don't know about you, but I don't mind waiting a week for the garbage men to come by. It's better than having to drive down to the landfill everytime I want to throw out garbage. Who knows, sometimes I might get lost and it may end up under my neighbors porch.
Don't fire the garbage men! Civil servants have their place in society!
That's a fantastic metaphor. Indeed, going to the dump (as we call it in the States) is a chore.
The cumalative brainpower of the CLR team is astounding. More to come...
Keep on posting,
Charles
No, our society don't need them any more, the MASM team can able to makes a robot(or automation tools) to do what the garbage men did!
the managed code slower than native code MUCH,so I prefer to manage memory by hand.
I am a VC programmer in china.
In china,most of programmers used to the VC and Delphi ,they never using dot net except the asp.net.the VC is a great programming tools in the world,we are worry about that the VC2005 will be a new garbage as VC2003 ,because of the JIT.
the MS will lose many C++ programmers,because we(most of c++ programmers) are prepare turn to JAVA ,and learning it NOW.
On one side, yes, managed code running on top of CLR is slower and more restrictive than unmanaged code. What benefit do I get from using it? I don't have to worry about memory management. I know my memory is safe without any leaks. How do I solve the speed problem? I go out and buy a faster processor and more memory (obviously a very western philosophy).
On the other hand, running unmanaged code is faster and more flexible than managed code. What are the problems with unmanaged code? As a programmer, now I have to spend resources on memory management rather than concentrating on the programs purpose. As a user, I have to trust the programmer's ability to manage memory. How do you solve this problem? Pray that all programmers are good at memory management. Yes, you tweak out every ounce of performance from your hardware (a very eastern philosophy), but when Dell is selling P4 2.x GHz, 512 MB systems for less than $400.00, why bother?
Do you drive a manual transmission or an automatic? (Please don't say you ride a bike!
I guess you haven't tried running JAVA apps on top of Windows lately. When I open up my Oracle utilities, I go for a cup of coffee.
To choice JAVA, absolutly wanna give up the win32 platform,meaning have no choice on win32 platform.
Your complaint is you don't like CLR because it's slow, but you'll move to JAVA, even though it's slower?
Isn't this a case of cutting off your nose to spite your face?
Or did I read it wrong? Are you implying you'll stop using Windows all together?
this is not a cultural problem, we all wanna make our application better and faster.
the memory management is a programmer 's job,it also can shows the ablity of programmer.the data structure is a subject of memory memangement.
Will you spend your money to buy a car that is slower than a bike?
if answer is yes, then i will buy that bike.
I disagree. The programmer's job is to accomplish the task the program is supposed to perform. If I pay a consultant to write me an accounting programming, I don't want 20% of my bill to be memory management coding time.
Or lack of ability. You may be a very good programmer, but I'll tell you there are a lot of bad programmers as well. Kind of like the saying, "Ugly girls need love too." Well, "Bad programmers need a job too."
I'm not sure I follow that metaphor. I'm guessing .NET is the car, but what's the bike? Unmanaged code?
My answer would be, I'd take the car, drop a 5.7L HEMI V8 340 HP motor in it, put some nice 21" Aluminum Alloy rims, pumpin' radio and safely cruz on by you on your bike, as I watch you dodging other bicyclists on your unmanaged road.
Then the CLR makes it possible for you to write code once and run it anywhere (x86, Itanium, AMD64, mobile devices), just in a different sense than Java. Then you can get native code-like performance with tools such as NGEN (except for the GC overhead, which is not that big actually). And there's much more to it. Great piece of software.
I hate doing plumbing, especially when I've done it a thousand times before. Doing memory management manually is fun the first few times for the sport of it, but it wears off after a while. Also, I, like most programmers I know, am lazy.
This is why even in C++ I typically resort to using std::string, std::auto_ptr and boost::shared_ptr. Especially when you're passing stuff around in containers a lot the shared_ptr is a blessing, no need to keep track of who owns what where and should delete it when, and no need to perform copying all the elements every time the container is copied.
That can be a negative as well though can't it. GC isn't a silver bullet, in Java OR .Net. The fact that GC insinuates that you can just fire and forget in terms of memory reclaimation tends to lead to laziness in thinking things through - I've seen plenty of java code where the developer is creating far too many temporary objects assuming that they will be GC'ed and then wonder why the memory use is still high a second or two after they have finished using the objects.
So I guess my point is, its nice, its useful - just don't take it for granted.
I didn't mean to focus on just a couple of features of the CLR. I'll let you guys in on a little secret. If my project is approved, the .NET team will be responsible for a revolution at the Chicago Police Department.
I've already completed one revolution by switching them from Linux/Sendmail to Exchange/OWA.
I'd love to talk to a few of the .NET team members privately to discuss details. Please email me at:
patrick.nguyen@chicagopolice.org
if you'd like to help me with this mighty undertaking.
Forgetting to Dispose classes is also a big problem. People assume the GC takes care of their objects, but the GC doesn't run all that often. So if you open a file and forget to Close it, it'll be closed only when the GC decides to finalize your FileStream object, and in the mean time it's locked. Here the simplicity of managed resource handling is making programmers forget that managed classes can still contain unmanaged resources. Resources that you may want to have freed before your object is GCed.
Laziness is no excuse to stop thinking. It is however an excuse to make life simpler for programmers everywhere.
As for the performance aspect, with modern high-speed computers as cheap as they are, execution time is a lot cheaper than programmers by the hour. So anything that makes programmers more productive is welcome.
Besides, because of RSI I'll take every keystroke I can save. That's also why I love the VB.NET editor so much, it's autoformatting and automatic insertion of certain constructs save a lot of keystrokes.
Actually managed envrionments go back 30 years at this point (Xerox Parc had a project called Cedar back then). The CLR has people who worked on the original lisp/scheme and smalltalk environments long before Java existed. Like any new system, we learned from the best thinking of the past and added our own to create a new system.
I remember switching to my first PC and typing at the DOS prompt:
10 print "Hello World!"
Then, getting an error message trying to type run, then list. After repeated errors, giving up and shutting it off. This is when I realized not all computers are alike. Hey, sounds stupid, but I think I was like 11 or 12 years old.
Kermit the Frog Here
Yes, this news comes from the MS pain-in-the-rear, Linspire, who was sued by Microsoft for infrindgement of trademark of "Windows", which ended up costing Microsoft millions of dollars instead. Ha! Ha! What a joke on Microsoft! (Get with rules of engagment, not your lies and deception!)
Now available. Windows Media for Linspire Linux
http://www.linspire.com/lindows_michaelsminutes.php
Read it and weap! I doubt Steve Ballmer can say anything about this move. I am sure Linspire worked out a deal that Microsoft can not back out of, in reagrds to Windows Media technology. because we all know how much Steve Ballmer HATES Linux would just love to see that penguin fry!
(the Commodore 64. The original! MS Windows - a rip off of everyone elses ideas, propagated by an illegal monopoly! Judgement Day is coming for you, MS. It is just a matter of time.)
Maoni also has a very good paper on the GC up on MSDN. I'd highly recommend giving it a read.
(OK, we did have some Chris Brumme videos a while back)..
The GC heap, statics, and stacks are all per-process data.
Comparing Java and .NET
K John Gough Stacking them up: A Comparison of Virtual Machines , Presented to the Australian Computer Systems and Architecture Conference, ACSAC-2001 Gold Coast, Australia, February 2001 (Draft Version)
and
http://www.cl.cam.ac.uk/~jds31/research/jvmclr.pdf
That's basically correct. If you adhere to using pure managed code, it is type safe and verifiable. You can write to any fields your type model allows, but not outside of that. JIT'd pages (including NGEN'd jitted pages) are 'x', but have also been verified as part of generation.
All bets are off if your code has p/invoke privileges. Because VirtualProtect is a kernel32 method, you have to use p/invoke to call it. You could have also called kernel32!DeleteFile at that point if you wanted to be maliciuos.
Note that unsafe IL (see the unsafe keyword in C# for example) can also allow you to do whatever you want.
Bottom line design goal was to make default applications stick to safe subset of the functionality, and give us the power to enforce that for things like downloaded code from the internet. But at the same time we want to give power programmers access to all the old bag of tricks so you have reach. You can take as much rope as you want and the end user executing your code allow you to have.
You're overloading the word "heap" in to mean too many things.
JIT'd pages are allocated in a VirtualAlloc range that are +x, otherwise we could not execute them. This is a JIT "heap" from that stand point.
Data can live either on the stack, or in the GC "heap". The GC heap pages are -x. Starting with XPSP2 stacks are also marked -x (NX, or No Execute). This is hardware enforced on chips like the K8 and above. This is an OS issue, not specific to managed code.
JIT'd code does not get to live either on the stack or in the GC heap. You could therefore write opcodes to your hearts content to a managed buffer but it will be in a VirtualAlloc range marked -x.
MC++ (the /CLR switch) produces by default untrusted code (there is a new "pure" mode in Whidbey, which is just like C#/VB.Net). Code Access Security (CAS) does not let you call it by default. You need the same permission to call it that you need to call an unmanaged method like kernel32!VirtualProtect or kernel32!DeleteFile. So the scenario you describe cannot happen unless you have already raised the privilege of the code to the point where there are far easier ways to hack the system than trying to write a virus to the stack. This kind of code is not allowed to run (by default) from the internet, for example. My mother will never raise the internet zone to allow the code to do this scenario.
There is no magic in the CLR here. We rely upon Windows to enforce -x behavior. Windows in turn relies upon the underlying hardware. As I mentioned, the K8 chip and above do have hardware enforcement.
Just to overcommunicate: "managed pages" for data == -x. "managed pages" for code == +x. Two separate "heaps".
"some type of protection" == CAS. The point is you cannot call any unmanaged functions from locked down code. All managed code you download from the internet is locked down by default, meaning no p/invokes == no virus generation/execution.
Hope this helps...
Dynamically JIT'd code is allocated in a heap which grows as you JIT more code. Since the code is per-process and not subject to movement, call addresses are VA's not RVA's.
NGen'd code is persisted out to disk in traditional PE file sections using RVA's that are fixed up at runtime. Becuase NGen precompiled all of the code, there is no dynamic JIT compile and therefore no heap involved for that assembly.
A "CS code segment" is the way a PE file describes code. JIT'd code is dynamically compiled == a heap, NGen code is pre-compiled and persisted to a PE file, therefore there is a code segment (look for '.text'). You can do a "link /dump" on a managed PE file to see the sections, their attributes, etc. Try to ngen a file and then do the same experiment (ngen'd file lives in %windir%\assembly\nativeimages*).
Hopefully the difference between JIT'd and NGen'd code is clear from the above.
Hey to be fair, I wrote the original file format spec and I have the benefit of working on the project for 7 years <g>
Read the book, and if you wind up with questions feel free to post on my blog for clarifications.
Or worse yet, your object may not ever be finalized (If I remember correctly the GC behavior when I was researching).
It's possible (short program, little memory usage) that the GC never runs before the program exit. Even though, the process memory is reclaimed, unmanaged resources may be left out there 'cuz the finalizer isn't executed.
Disclaimer: The GC's behavior changes so many times, what I said could be totally off.
That is true. It's probably worse for DB connections. Also, I wonder if an ASP.net page leaves a file handle opened, so if IIS is the process, then that handle doesn't get reclaimed until IIS is reset (ouch!)
Remove this comment
Remove this thread
Close