Jason Zander - Tour of the .NET CLR team

The Discussion

• 

  Yeah!  I always love meeting the garbage men!  Without you garbage collectors, the world would be a mess! 
  
  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.    I'm not sure, but maybe the difference is in the JIT compilers.  Or maybe it's because it's called MSIL now and not bytecode.  Well, whatever the difference, CLR is a godsend and the world would be messy without you garbage collectors! 
  

• 

  Slow........
  should fire all members of the CLR team ,
  and replace with the MASM team.
  the garbage always makes a garbage!!!
  

• 

  leighsword wrote:

  Slow........
  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!
  

• 

  dugsnake wrote:

  
  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. 
  

  
  
  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

• 

  Great to see the interior of Bldg 42 again Can't wait to see the perf team

• 

  dugsnake wrote:

  
   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!
  

  
  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 JAVA, i have fotgot to metion it.
  the MS will lose many C++ programmers,because we(most of c++ programmers) are prepare turn to JAVA ,and learning it NOW.
  
  
  

• 

  I see there is a cultural difference here.  I can see your point.
  
  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!    )
  

• 

  leighsword wrote:

  the JAVA, i have fotgot to metion it.
  the MS will lose many C++ programmers,because we(most of c++ programmers) are prepare turn to JAVA ,and learning it NOW.
  

  
  
  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.
  

• 

  dugsnake wrote:

  leighsword wrote:the JAVA, i have fotgot to metion it. the MS will lose many C++ programmers,because we(most of c++ programmers) are prepare turn to JAVA ,and learning it NOW.

  
  
  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.
  

• 

  leighsword wrote:

  dugsnake wrote: leighsword wrote:the JAVA, i have fotgot to metion it. the MS will lose many C++ programmers,because we(most of c++ programmers) are prepare turn to JAVA ,and learning it NOW. 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?
  

• 

  dugsnake wrote:

  I see there is a cultural difference here.  I can see your point.
  
  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!    )
  

  
  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.
  

• 

  leighsword wrote:

  
  the memory management is a programmer 's job
  

  
  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.
  

  leighsword wrote:

  
  it also can shows the ablity of  programmer
  

  
  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."    At least as a user, I won't have to worry which type of programmer wrote the program I'm using.  Especially, I'm hoping I won't see the BSoD as much.
  

  leighsword wrote:

  
  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'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.
  

• 

  Actually, you talk about automatic memory management and JIT compilation, but the CLR is about much more than that. It has a full-blown security engine (if you RTFM you can write apps that run as administrator and yet have no rights over the system), the loader and the related components are a piece of jewelry because they're one of the most advanced attempts to solve common issues such as versioning vs. ease of deployment vs. serviceability.
  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.

• 

  And the CLR GC is much better controlable than the Java GC.
  
  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.

• 

  Sven Groot wrote:

  Also, I, like most programmers I know, am lazy.

  
  
  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.
  

• 

  Well, to put it simpler, a fool with a tool is still a fool Having better tools doesn't mean one should stop thinking.

• 

  Ovidiu.Platon wrote:

  Actually, you talk about automatic memory management and JIT compilation, but the CLR is about much more than that. It has a full-blown security engine (if you RTFM you can write apps that run as administrator and yet have no rights over the system), the loader and the related components are a piece of jewelry because they're one of the most advanced attempts to solve common issues such as versioning vs. ease of deployment vs. serviceability.
  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 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.
  

• 

  Of course being lazy can be bad. But typically, lazy is a good thing for programmers. It inspires reuse and technologies like the GC. I realize the GC is no end all solution. If it were, then why do we still need a StringBuilder class, or the IDisposable interface.
  
  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.

• 

  These are all good points Sven.  We've seen dramatic improvments in productivity for programmers no longer strapped down by memory pointer errors.  However one still needs to think through their design.  Excessive pinning of objects can cause framgementation, and keeping huge trees of objects rooted can exhaust memory unecessarily.  We've got a lot of good documentation and some tools (like CLR Profiler) designed to help.

• 

  dugsnake wrote:

  Still sounds a little like a JRE though. 
  

  
  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.

• 

  My first computing experience was in a managed environment!  Good old C64.
  
  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.
  

• 

  News Flash! - The Secret Behind Windows Media (on Linux!)
  
  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.)
  
  

• 

  In the video, Michael is using our NTSD debugging extension called SOS.DLL.  There are several very handy internal debugging commands there.  You can read more on Michael's blog.
  
  Maoni also has a very good paper on the GC up on MSDN.  I'd highly recommend giving it a read.

• 

  At last, after months of Channel 9 videos we've found the MS team where the real geeks hang out!
  
  (OK, we did have some Chris Brumme videos a while back)..
  

• 

  The only thing we share between processes is read only assembly data, such as the metadata definitions and the IL code.  In addition, if you have ngen'd your code then those pages are shareable as well.  I have an NGEN overview on my blog that explains it in more detail.
  
  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

• 

  Beer28 wrote:

  EDIT: actually, I'm sorry I asked, there's probably no way .NET gives the app access to it's managed memory. I'd think anyway, much less access control. Basically, the CLR treats it like the MSJVM and VBVM as far as access I suppose. I was originally thinking you could pin the pointer down then VirtualProtect it to rwx. I guess that would make for a bad VM though if that was possible.
  

  
  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.

• 

  Beer28 wrote:

  
  OK, so wait a second, you are now saying the heap pages in the CLR for your app are +x ?
  

  
  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.
  
  
  

  Beer28 wrote:

  
  So what's stopping you from pinning down a pointer and writing a function out as opcodes to that pointed address, assuming it's also +w ?
  Then you could just call the function from C++ /CLR and have the the function exec from inside the CLR with the CLR's privilages right?
  

  
  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.
  
  
  

  Beer28 wrote:

  
  Is there hardware page protection inside the CLR assuming you could get native code to execute in there?
  

  
  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.
  
  
  

  Beer28 wrote:

  
  I thought calling kernel functions on your managed pointers or memory would not work because of some type of protection. Granted I never actually tried it, but I didn't think the managed pages were +x or accessable from outside API.
  

  
  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...

• 

  Beer28 wrote:

  ok, so in the CLR the virtual code segment is a heap (dynamically growing) instead of a fixed paged section with RVA's as call addresses?
  

  
  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.
  
  

  Beer28 wrote:

  
  So there isn't a CS code segment offset in JIT'd code, the runtime has the CS address and runs the code in a heap like the JRE right?
  

  
  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*).
  
  

  Beer28 wrote:

  
  I was under the impression that after it was JIT'd the code was loaded and run with it's own LDT and segment offsets for cs, ss, and so forth. I'm getting the impression that it's still in it's code fragments and strung together by the VM at execution time.
  

  
  Hopefully the difference between JIT'd and NGen'd code is clear from the above.
  
  

  Beer28 wrote:

  
  Actually, I don't wanna be any more of a pain in the butt, I'll just read the rest of inside the CLR instead, thanks
  

  
  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.

• 

  Sven Groot wrote:

  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.
  

  
  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.
  

• 

  Even if that were to happen in the case of the file it's not so bad, because open file handles are also reclaimed by the OS when the process quits.

• 

  Sven Groot wrote:

  Even if that were to happen in the case of the file it's not so bad, because open file handles are also reclaimed by the OS when the process quits.

  
  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!)
  

• 

  It is interesting to note the same kinds of memory management bugs of 30 years ago occur today.  The technology for resolving them is oh so much better, but I have often had to put PRINT statements into memory managers to detect by whom, when, why and in what order some buffer got doubly allocated or orphaned.  Fortunately, these bugs are now closeted away from application programmers.  They are left for the systems programmers of Washington State to detect and destroy. One machine I worked on had an 18-bit address of 36-bit words.  Inside the OS these addresses were not relocated; they pointed to actual hardware locations.  It was great fun when code using these addresses ended up clobbering memory completely unrelated to the code's function.  Evidence that such corruption happened could be detected literally days after it happened.  Tracking such phenomena back to the point of origin was very, very difficult.   Eventually the hardware evolved to the point that so-called absolute pointers into memory were abolished so that memory limits registers were always used and corrupt pointers usually caused an immediate, diagnosable machine stop.  But I digress.