To read all comments associated with this story, please click here.
Interesting, and thanks for correcting me. I've always been under the impression that CLR = MS's implementation of the CLI, which in turn = a good part of the .Net Framework and therefore the same version. MS's versioning scheme is cryptic to say the least, ala according to your info the following is true:
- We're on v3.5 of the .Net Framework
- We're on v2.0 of the CLR
- C# is in v3.0
Are you sure about Java inlining virtual methods? I just did a quick Google and wasn't able to confirm that. I thought that by definition, a virtual method cannot be inlined which is why a lot of folks were concerned about all methods being virtual in Java by default. I'm by no means versed in compiler theory, but I don't see how a virtual method can be inlined.
http://portal.acm.org/citation.cfm?id=353191
Method devirtualization has been around in the JVM for quite a while. That paper (sadly requires a subscription) does a moderately good job of covering the various techniques used.




Member since:
2006-03-01
No. If you run a low level program such as http://www.codeproject.com/dotnet/DetectDotNet.asp to enumerate the available CLRs on a machine where .NET framework 3.5 is installed, you get the following:
Is .NET present : Yes
Root Path : C:WindowsMicrosoft.NETFramework
Number of CLRs detected : 2
CLR versions available :-
1.1.4322
2.0.50727
Press any key...
If you use shared mutable state for communication between threads, you have not much choice but to use locks.
But there are safer alternatives such as message passing. Of course somewhere deep in the message queue code there will still be a lock or some other low level synchronization primitive. But an application programmer will never have to mess with that. See the BeOS API for pervasive use of message queues.
The biggest performance problem is this: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.asp.... This can lead to a factor 5 to 10 performance degradation compared to C++ when doing numerically intensive code. Still much better than java though, since java does not have structs at all.
Fortunately, this will be addressed in the next (3.0) release of the runtime.
But there are various optimizations that java VMs have been doing for ages that the CLR does not do, such as virtual method inlining. And the CLR also does not even attempt to vectorize code on CPUs with SSE3.
Edited 2007-12-03 14:03