Andrew Stopford's Weblog

CLR Panel notes

Thanks to Brad for the link and Jason for taking the notes, some great questions and answers here. Some that caught my eye and my thoughts.

Q:  How low can you take the CLR, eg: could it go down into the kernel.

Patrick:  Two versions of the CLR could be made, one with high availability which runs in kernel mode.  The other is the normal CLR as you know on top of that.  AppDomains could become the next version of a Process on the machine.

Working directly in the kernel could be an interesting approach, from a Rotor view the kernel is sat below the PAL so the approach is how  do you write it so that it can be run in a Kernel in a modular way (that is run across a range of different Kernels). Do you retarget the code in the way the PAL is, that is make OS targets for items such as SEH hardware failures, JIT etc. It would be much more involved (you would be hooking the code into the level above the PAL) but more low level and you could hook into OS calls, threads and messages directly with out making any PAL translations.. This approach would call for a lighter abstraction layer, a little like the PAL but just serving a common gateway of calls that the Kernel can make into the rest of the runtime. Of course this layer would still need to provide PAL functionaility that is hard wired in when the OS cannot provide, SEH is a key example here, but for everything else this could work.

Q:  Have you considered how you can get OS VM and GC to communicate?

Patrick:  Lot of OS system services already there (eg: GetMemoryStatus) to auto tune the load on the machine.  If you are in 90% utilization, CLR GC will back off on allocation pressure.  In XP there is a new low memory notification service.  Finalizer thread in 1.1++ CLR uses this to also back down.  Future directions should include the CLR being able to get a "budget" from the OS, and then the OS could guarantee that without paging and CLR could auto tune within that limit.

This is something the PAL could do, making a call into its target OS to obtain that budget and setting the runtime to obey that limit. I am curious to know if the 1.1 feature mentioned is in the Rotor code (not seen any referance to it), would be interested to see how that works in a PAL (as it uses a XP feature). I would be interested to see how this could be made into a hardwired PAL feature, that is keep tabs on memory (or where the OS allows make system calls to do this) and when memory allocation runs low raise the same message (or could it be treated as a SEH hardware exception that Rotor internally intercepts). I will add this to my list of things to explore as me and Robert work on our Linux port.

and of course

C:  Thanks to Chris for an excellent blog <applause>

I second that ;-)

Peter Drayton

PDC CLR track slides

• CLR Under the Covers: "Whidbey" CLR Internals
• CLR: Tips and Tricks for Faster Managed Code: How To and What's New
• CLR Under the Covers: .Net Framework Application Security

Ecma Moves to Standardize C++ Binding for CLI

Yukon

Avalon and XAML, Royale, Laszlo and MXML

Had to happen, XAML compared to XML language based vector GUI's (namely Laszlo, MXML/Royale and Central). There was some confusion in the post on what Avalon was attempting, Jeremy makes some good points on Central and Avalon.

Central is also not a player/browser model, but a new desktop shell.

Thats very much Avalon then, will be interested to see how this technology shapes out.

I can't take this

PDC Rotor BOF

The Rotor BOF took place on Sunday, Robert reports that Sam helped out on the session and that Brad and the CLR group at Microsoft have taken over running Rotor alongside the main CLR. This means that changes to the main CLR are then checked against the Rotor code to ensure that the PAL works fine (and thus works on other platforms), as Robert says that's good news for our Linux port. One item from the session to note:

Brad Abrams wanted to know whether anyone was interested in using the JIT compiler and making it available in the Rotor distribution - you couldn't modify it but it would allow for better performance

Rotor already has a JIT so I can only assume that its a subset of the commerical JIT and its the commerical JIT that Brad is talking about, maybe Brad can clear that one up? The new JIT may present a few issues, seeing what is different between the commerical JIT and the Rotor JIT would I admit be useful but I am unsure what its impact would be on anyone wishing to introduce a new JIT. Indeed would the new JIT be available in source form? So many questions ;-)

Parrot, PHP and is the CLR limited

Sam Gentile

Sam has blogged that he may have leave the PDC to attend to family issues, I have read that a lot of airports have been closed due to the wild fires. Should Sam need to get home I sure hope he can. My thoughts are with you Sam.