John Lam and Martin Maly: Deep DLR

Posted By: Charles | Mar 24th @ 6:03 AM

Dynamic languages are becoming more popular than ever. Static runtimes (static type system is baked into the machine) like the CLR do not natively support languages that have no requirement for explicit types. Implementing languages of this class on the CLR is a rather complicated and arduous task. Some very clever folks like Program Manager, RubyCLR creator and IronRuby team member John Lam and Senior Software Developer Martin Maly (creator of the LOLCode programming language implementation that runs on the DLR, but more importantly one of the devs who writes the DLR) are on the team that makes implementing dynamic languages that can run on top of the CLR not only possible but easier than one might expect. This is made possible with a new managed virtual machine called the Dynamic Language Runtime (DLR). The DLR runs on top of the CLR, but you can think of the DLR as it's own managed runtime (or virtual machine). For this interview, it is assumed that you have working knowledge of what the CLR does.

This interview focuses deeply on one core question: How does the DLR work. Of course, we talk about the history and future of the DLR, but primarily we find out about DLR nuts and bolts and architecure.

This interview is whiteboard heavy and compelling. It was really fun to chat with John and Martin and geek out on the DLR. It is a great technology with a very bright future.

Enjoy!

Low res file here.

Tags: CLR, DLR, Programming

Rating:

Views (15,509)

Comments (10)

Downloads

NickHodge
NickHodge

LOLCODE on DLR

Codeplex the version you have!

NickHodge
NickHodge

LOLCODE on DLR

Codeplex the version you have!

gaurav.net

supercool... thx for this one... DLR is the future..(ruby is gr8 lang)

littleguru
allein, allein,... allein, allein!

Martin rocks!!

littleguru
allein, allein,... allein, allein!

I have a few questions:

What happenes with the no longer valid code? Like if the version gets up what happens with the no longer valid IL and tree. I understand that the tree just gets dumped but is there a concept to removed the jitted IL of a method, or how is this solved?

Let's say I have this + operation for int and int. Now the tree gets generated and some piece of IL and at the end the Help call. What if next comes in a + string string. Is the whole + int int regenerated or do you create the + string string IL in a method and add the call to the old + int int delegate at the end? Or are you holding like a list internally that holds all the delegates for the different + operations and you invoke them one by one?

bobsmith2008

it wont be long before dynamic languages become the main, same as dynamic content.

JohnLam

In the fully dynamic mode, and if IL is generated (as opposed to the trees being interpreted), the IL is generated as CLR Dynamic Methods which are eligible for GC.

If I understand your second question correctly - the original site is replaced by the new site.

littleguru
allein, allein,... allein, allein!

JohnLam wrote:

In the fully dynamic mode, and if IL is generated (as opposed to the trees being interpreted), the IL is generated as CLR Dynamic Methods which are eligible for GC.

If I understand your second question correctly - the original site is replaced by the new site.

Ah! Seems like I had a blackout on the GC part... sorry.

Generating the new side means that you generate the whole IL for the + int int again (let's suppose the first side had already the code for the + int int in place and you add a + string string)? Isn't generating the new side going to be slow ower the time as you add new cases? I'm curious whether you guys have seeen performance decreases there... you probably did a lot of performance measurement...

Another thing: from time to time I'm using custom runtime code generating for the CLR too (like TypeBuilder, AssemblyBuilder, DynamicMethod, etc.). I wonder if you guys have public benchmarks on how fast/slow stuff is and/or guidelines that show us what should be avoided etc...

Thanks in advanced.

sokhaty

Good video, really scratches the surface Smiley
Any chance of seeing continuation of DLR discussion any time soon?

Also, if a dynamic language chooses to implement n-ary operators, then pathological cases may become not-so-pathological at all. Not that I'm aware of any such language, but still.

If I understand it correctly, the number of trees cached at a dynamic site is K^N (K being operators arity and N being number of types operation can be performed upon).

Currently DLR seems to rely on equivalents of IF…THEN statements to call proper implementation of the operator depending on the type of passed in arguments.

Wouldn't it make sense to allow dynamic language implementer (and presumably developer by proxy) to specify whether to rely on IF…THEN chains or use something like a hash table of delegates, where hash key will be produced using the list of operand types?

And finally, if adding apples to oranges is not a supported operation in a language and while asking the language DLR will get back an exception, will DLR try to "remember" that or on the next occurrence of add(apples, oranges) it will ask for help again? Shouldn't it be also somehow configurable?