How It All Started…AKA the Birth of the CLR

Check out the CLR Lead Architect's New Blog

Maoni's WebLog — Wed, 22 Nov 2006 23:44:49 GMT

Many people know Patrick Dussud by his outstanding work on Garbage Collection. But did you know he was

re: How It All Started…AKA the Birth of the CLR

shailensukul — Thu, 23 Nov 2006 01:38:54 GMT

The first article was a great recap.

I would love to see an article on the extensability features of the CLR.

Thanks

Shailen

re: How It All Started…AKA the Birth of the CLR

Mike Dimmick — Thu, 23 Nov 2006 02:20:24 GMT

Can you talk about how much of the problem with the JVM was technical and how much political?

С чего начинается CLR

Items — Thu, 23 Nov 2006 17:34:30 GMT

Не так давно начал свой блог самый главный разработчик .Net CLR и вообще хороший человек Patrick Dussud

re: How It All Started…AKA the Birth of the CLR

Hideki A. Ikeda — Thu, 23 Nov 2006 20:20:01 GMT

In your future blogs, I would like to read more about GC.

re: How It All Started…AKA the Birth of the CLR

mjeelani — Thu, 23 Nov 2006 20:26:24 GMT

Great Post Patrick! Looking forward to more insights on the CLR.

re: How It All Started…AKA the Birth of the CLR

tomasr — Thu, 23 Nov 2006 22:12:11 GMT

Great stuff Patrick, and welcome to the community! I wonder at what point did the COR name appear?

re: How It All Started…AKA the Birth of the CLR

demattel — Fri, 24 Nov 2006 13:35:08 GMT

In Common Lisp? Great! Can you write more on this topic?

re: How It All Started…AKA the Birth of the CLR

shakeher — Sat, 25 Nov 2006 08:56:07 GMT

server modelling ---- how about a bit of its history too. seriously,the above history was great.

re: How It All Started…AKA the Birth of the CLR

Christian Kiefl — Sat, 25 Nov 2006 09:09:23 GMT

I'd like to read about WHY you used LISP at first.

Nice Post. A bit short perhaps ;)

Patrick Dussud on CLR history

Brad Abrams — Sun, 26 Nov 2006 21:19:42 GMT

Patrick , one of the founding members of the CLR team, starts a blog by posting a brief bit about this

re: How It All Started…AKA the Birth of the CLR

rbirkby — Mon, 27 Nov 2006 01:48:52 GMT

> and a new cool language: C#

ho ho ho!

For an alternate view on the gestation of the CLR check out:

http://discuss.develop.com/archives/wa.exe?A2=ind0008&L=DOTNET&P=R9831&I=-3

re: How It All Started…AKA the Birth of the CLR

ovidiupl — Mon, 27 Nov 2006 22:46:59 GMT

I'd like to know what order the pieces were built in (specifically: metadata, IL and the JIT compiler, the GC, the security subsystem, AppDomains). It would also be interesting to know what were the goals and the constraints that guided design choices (for instance, why not build a simpler runtime, like a garbage-collected environment for C++, without IL?)

Patrick Dussud ouvre un blog

CoqBlog — Tue, 28 Nov 2006 01:39:21 GMT

Vous l'avez sans doute déjà lu, Patrick Dussud , ouvre un blog . Patrick Dussud est un des ingénieurs

re: How It All Started…AKA the Birth of the CLR

Patrick Dussud — Tue, 28 Nov 2006 01:53:37 GMT

About Common Lisp and Lisp in general:

I have worked on Lisp for many years, and I think it has strength that sets it apart from other dynamic languages. My favorite is the fact that you can extend the Lisp language to create your own special purpose language in a very natural way using macros. Lisp has a very simple syntax (prefix notation). As long as your extensions adhere to that syntax, it is possible to make them seamless. Arguably, CLOS is a very large extension to Common Lisp, even though you don't need *any* compiler changes to do a pretty good job implementing it on top of regular Common Lisp.

Last year, I gave a talk at the International Lisp Conference about the need for Lisp to integrate with the CLR (and / or Java). See the following URL

http://www.international-lisp-conference.org/2005/speakers.html#patrick_dussud

re: How It All Started…AKA the Birth of the CLR

Patrick Dussud — Tue, 28 Nov 2006 02:14:50 GMT

About the GC prototype in Common Lisp.

A GC system is rather intricate; besides the basic GC components themselves (the memory manager, the object tracing mechanism, the compaction/sweep/copy module, the finalization mechanism) there is a great deal of support coming from the execution engine: root enumeration (from the global roots and the stack), synchronization between the execution engine and the GC, initialization and orderly shutdown. Rather that working on all of the pieces together, I decided to write a simulated environment where I could concentrate on the GC components and once they are working, then I would get it in the execution engine. This way, I wouldn't be tempted to bend the design of the GC mechanism to satisfy an oddity of the execution engine.

At the time I wrote it, I could also have used VB, C++, Java. Common Lisp had the best debugging support at the time and I knew how to write a source to source language translator as long as the input source language is Lisp (I wrote an Interlisp to Common Lisp one at Schlumberger and a Zetalisp to Common Lisp one at Texas Instruments).

I wrote the code in stylized Lisp, keeping in mind that I had to translate the code to C++, so no advanced Lisp features were used (no dynamic feature, no closures).

Unfortunately, I can't find the Common Lisp GC sources or the translator anymore; they were left behind on one of my development computers. :-(

re: How It All Started…AKA the Birth of the CLR

Patrick Dussud — Tue, 28 Nov 2006 02:26:52 GMT

About JVM limitations:

Well, the JVM has technical limitations that were hard for us to solve: the JVM is designed to execute type safe languages only and we wanted to executed unsafe C++ as well. Solving this would have required the support of the entire Java community and this didn't make sense for the community at large.

Other limitation were contractual. We discovered that the compliance test suite didn't allow us to extend the existing Java classes so it was hard for us to reflect the Windows platform with more fidelity.

We also discovered that it was very hard to negociate for a different / better Java to Native code interop layer. This was both a technical and political issue: the interop layer is heavily archicture specific - it is hard to make it universal aka Run anywhere- and it is quite visible to programmers unlike an extension library on the side.

re: How It All Started…AKA the Birth of the CLR

Patrick Dussud — Thu, 30 Nov 2006 02:30:28 GMT

About the rationale for our design decisions:

First and foremost, we wanted to support safe execution of type safe languages . We designed a security model to separate trusted code from untrusted code and app domains to isolate code execution contexts from each other. We also wanted to be able to recompile an existing C++ application with an extra /CLR flag and run this application under the CLR. These high level goals lead us to where we are now. We briefly thought about a small GCed runtime for C++ but because C++ isn't type safe, it wasn't that interesting to us. Also you are severely limited in the ability to manage memory automatically for a language which can "hide" references in other datatypes or even by adding extra bits to the reference and such clever tricks.

New and Notable 127

Sam Gentile's Blog — Wed, 03 Dec 2008 21:20:37 GMT

I thought Thanksgiving morning is for adults to be sleeping in. Instead, not only are the kids up at the crack at dawn but one (the eight year old) is playing games on Vista and asking for Starbucks, while the nearly 4 year old is clamoring for princess

re: How It All Started…AKA the Birth of the CLR

sinetif — Sat, 03 Jan 2009 10:53:24 GMT

"Other limitation were contractual. We discovered that the compliance test suite didn't allow us to extend the existing Java classes so it was hard for us to reflect the Windows platform with more fidelity."