managed code?

Possibly.

Java itself is not "managed" because Microsoft reserves that word to mean "under the domain of the .NET framework and the Common Language Runtime system." Sun''s VM is not that. Microsoft is no longer shipping a Java VM, you may have noticed.

The Microsoft CLR interpreter and byte code may be designed to run faster than Java. The Microsoft garbage collector may be designed better than the Sun garbage collector. The CLR may decide that when you''ve taken some loop 100 times, it''s probably CPU intensive, and re-compile it to native code for speed behind your back. Heck, the CLR may decide to compile your entire application to native code on load.

You don''t know, and, what''s worse, you can''t find out, because the click-to-install license says that you can''t post benchmark numbers of the CLR implementation publicly without Microsoft''s permission.

quote:

---

Original post by hplus0603
Heck, the CLR may decide to compile your entire application to native code on load.

---

It does. That''s what a JIT is.

There''s "managed code" and there''s "managed code". Using MC++, for instance, one can compile (for the most part) vanilla C++ programs, generating IL, but having no verifiability, reflection, garbage collection, or anything else (i.e. no managed types or managed data). Occasionally (especially in older documents) MS refer to this unverifiable unGCed code as "unmanaged"; normally they use "unmanaged" to mean "native". The terminology has shifted a little, I think.

Personally, I rather prefer using "unmanaged" to mean "IL but not verifiable/GCed/etc.", and use "native" to mean, well, "native".

quote:

---

Also on a side note, you can "Pre-JIT" code using a utility in the .Net Framework which converts the app to native at install time, this may sound good but it can make a program slower rather than faster since it looses the runtime optimisations.

---

In current release versions of the runtime, the exact same code generator is used for both JIT and PreJIT compilation. It would be nice if JIT compilation gained PGO, but it doesn't have it yet.

quote:

---

On Longhorn, Unmanaged applications(or "native" if you prefer) will be subjected to the same checks as Managed .Net applications this in itself may cost a frame or 2 anyway, Windows Longhorn itself is in Managed .Net because C# seems to be able to use Assembly to talk to hardware.

---

They won't be subjected to the same checks, because they can't be subjected to the same checks. Too much information is lost in the compilation process. Longhorn itself is for the most part written in C and C++. Its shell will be written in a .NET language, parts of DCE will probably be managed, but nothing under the bonnet (kernel, native API, drivers, Win32, .NET runtime itself) will be.


[edited by - DrPizza on January 21, 2004 12:57:11 PM]