What is missing from the CLR (2010 update)?? | The Coffeehouse

DouglasH
Just Causual

http://channel9.msdn.com/posts/TheChannel9Team/Brad-Abrams-What-is-missing-from-the-CLR/

can we revisit this topic from 2004??

since that was way back before whidbey was released. now what is missing from the CLR updated to 2010 would be an interesting revisit.

Continuations, and Mixins would be a good discussion.

Thanks Douglas

ManipUni
Proving QQ for 5 years!

Why did you decide to call the topic what you did? Wouldn't have "What is missing from the CLR (2010 Update)?" be more appropiate? I'm not sure what you want on this thread, discussion about the CLR or discussion about if old threads should be revisited?

joechung

Links from the new editor don't work?

Anyways, IL for vector and matrix operations would be nice, particularly if the compiler was smart enough to map them to SIMD instructions in CPU's (and GPGPU's) that support it.

Bass
www.spreadfirefox.com/5years/

What about multiple inheretence? Or is that supported?

raptor3676

In reply to Bass

#May 16th @ 4:45 PM

inheritance altough desirable, is something I can live without. For the upcoming CLR release I'm more concerned about performance, for the whidbey CLR the main issue was the JIT-Compiler not inlining any function with ValueType variables for instance.

I'd love to hear more about it here on the 9, hope Charles is reading this and accepting suggestions Smiley

stevo_
Human after all

In reply to Bass

#May 16th @ 4:45 PM

Why? it would make things really messy and you really couldn't add it in now.. most anything you think multiple inheritance could be used for probably just needs to be better designed.

Bass
www.spreadfirefox.com/5years/

In reply to raptor3676

#May 16th @ 7:10 PM

Isn't that a compiler issue though? Anyway are we even sure that Microsoft is going to change the CLR? They haven't since .NET 2. I don't think there really is all that missing from the CLR, that can't be implemented as a compiler feature or on the DLR.

Dexter

In reply to Bass

#May 17th @ 7:50 AM

While it's possible to implement multiple inheritance in the compiler (for example the C++ compiler does this when targeting the CLR) it's unlikely you really want that to happen. It wouldn't make sense to call it the "common language" runtime if you start implementing such important features in compilers.

Besides, adding multiple inheritance to an existing compiler/runtime that only supports single inheritance is far from being a trivial problem. It virtually affects every part of the runtime: the IL, the jit compiler, the garbage collector, all the compilers and languages that target the CLR.

Call me pessimistic but it won't happen Smiley

Charles
Welcome Change

Interesting that you bring this up... It just so happens that I will be releasing several interviews I conducted recently with many of the CLR's core teams to focus on the specifics of what they've been working on and will ship in CLR 4... It's been way too long since I visited CLR World. It was a refreshing experience!

All of these interviews were with the architects, developers, testers and PMs who make the CLR. I think you will be most pleased with the depth of conversation and the personalities in the frame. The CLR team is full of so many bright and passionate people. They've innovated big time in the next version of the virtual machine that powers all things .NET. You will learn all about it in the near future...

CLR 4 on Channel 9. Stay tuned. Smiley

C

JoshRoss
A righteous infliction of retribution manifested by an appropriate agent.

How about a multithreaded GC? Maybe someone could use the methods deployed in the Windows 7 dispatcher lock to solve this vexing issue.

raptor3676

In reply to Bass

#May 17th @ 7:50 AM

It is a compiler issue, but for C# and VB. NET, The bulk of the inlining decision effort is left to the IL compiler among other optimizations..

AFAIK, only the C++.net compiler, runs a fully through analysis on your code to check for such optimizations before translating the code to IL. But of course that only goes for your code; the whole BCL, is left out. Therefore the importance of having this in the IL compiler.

Anyway, C, seems to be paying attention... soon there will be more ligth.

littleguru
<3 Seattle

In reply to Charles

#May 17th @ 11:31 AM

Yipeeeee! Smiley Can't wait for it!

joechung

In reply to JoshRoss

#May 17th @ 6:57 PM

The garbage collector can already be multi-threaded if you configure it. There's a concurrent workstation GC mode and a server GC mode.

JoshRoss
A righteous infliction of retribution manifested by an appropriate agent.

In reply to joechung

#May 18th @ 1:24 PM

Concurrency happens! Interesting.

Charles
Welcome Change

In reply to JoshRoss

#May 18th @ 3:00 PM

The server GC has always been a concurrent GC. For CLR 4, they have created the first iteration of a new desktop concurrent GC not called Microsoft Desktop Concurrent GC 2010 Beta 1. Smiley

You'll soon hear all about this from the dev who writes most of the GC and the GC PM.

C

JoshRoss
A righteous infliction of retribution manifested by an appropriate agent.

In reply to Charles

#May 18th @ 5:08 PM

If its not called Microsoft Desktop Concurrent GC 2010 beta 1, may I name it corpus callosotomy? Imagine that, software products named after medical procedures!

Charles
Welcome Change

In reply to JoshRoss

#May 18th @ 9:17 PM

Interesting. Although I'm not sure the split-brain analogy works, precisely. Splits happen, yes, but as internal components of the unified brain, requiring communication in the singular concurrent sense. Smiley

Splits happen,

C

Dexter

In reply to Charles

#May 18th @ 5:08 PM

There's a blog post about GC in .NET 4.0 and it's quite old. Seems that the people missed it:

http://blogs.msdn.com/maoni/archive/2008/11/19/so-what-s-new-in-the-clr-4-0-gc.aspx

rhm

Is the .NET 4 going to support code unloading? I know it's hard, but so is everything in CLR-land and Java has been able to GC code since fairly early versions of the JVM.

And yes, there are AppDomains that you can load code into and then kill the whole AppDomain, but that means you incurr marshalling overhead every time you call into it. Also .NET2 introduced DynamicMethod class, but that again was a workaround rather than a real solution.

Charles
Welcome Change

I just posted a conversation I had with Vance Morrison, CLR architect and the father of MSIL. I'd encourage you all to watch and listen closely to what Vance has to say. Enjoy!

http://channel9.msdn.com/shows/Going+Deep/Vance-Morrison-CLR-Through-the-Years/

C

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to Charles

#May 19th @ 8:56 AM

That link is not a link.

Charles
Welcome Change

In reply to Sven Groot

#May 19th @ 8:59 AM

Yes. The editor is broken. Let me manually fix it...

C

EDIT: Duncan has been informed. Apparently, the editor creates relative path strings out of URL input data: removes the protocol and domain from the URL...

exoteric
I : Next<I>

I would think mixins could be fully implemented as a bytecode-compile-time feature, thus requiring no involvement on part of the CLR.

DouglasH
Just Causual

In reply to Charles

#May 19th @ 9:02 AM

Thanks Charles that was an interesting interview. Abstract? interfaces sound very interesting. sort of a poor mans mixin??. But something that is sorely needed in OO either way as Interfaces versioning currently is a Pain.

Isolation and message passing will be interesting in how it is integrated into the current languages. I know Axum is playing with it in a non class based way, haven't started playing with it yet. Been playing more with F#.

Exoteric, that may be the case, I know IronRuby have implemented mixins. But is that because of DLR, I know there was a talk at last years Lang.net where mixins were implemented also for C# but they were asking for language support. Mixins solve a lot of the multiple inheritance issues without alot of the issues. (Ruby is a single inheritance language also).

Continuations??

thanks Douglas

Charles
Welcome Change

In reply to DouglasH

#May 19th @ 12:42 PM

Not abstract interfaces (that was typo due to early morning typing...) Smiley Interfaces are by definition purely abstract (they lack any sort of implementation of their members...). The thinking is around default interfaces (interfaces with some default implementation of members).

Glad you liked the conversation. I just interviewed Vance again for a dive into Type Equivalence (including another architect you haven't met yet, but will in this piece and an earlier one covering No-PIAs in .NET 4).

C