PDC CLR Architectur Panel


October 30, 2003



font-size:10.0pt'>CLR Panel Discussion

following is the "transcript" I took of the "Designing the
CLR" Panel discussion.  We had
probably around 200 people in attendance, with an open mic forum. style=3D'mso-spacerun:yes'>  The Panel was swamped with standing ro=
om only
folks at the end (about 40 up around the stage with lot's of questions). an
style=3D'mso-spacerun:yes'>  At the panel we had Brad Abrams (CLR B=
Anders Hejlsberg (Distinguished Engineer, C# architect, Chris Brumme (CLR
Architect), Patrick Dussud (lead CLR Architect), Jim Miller (CLR Architect),
Sean Trowbridge (CLR Architect), George Bosworth (CLR Architect), and Jonat=
Hawkins (CLR PM/Moderator).


.0pt'> style=3D'font-weight:bold'>Q:  pan>How
low can you take the CLR, eg: could it go down into the kernel.

.0pt'> style=3D'font-weight:bold'>Patrick:=
Two versions of the CLR could be made, one with high availability wh=
runs in kernel mode.  The other is=
normal CLR as you know on top of that.Â
AppDomains could become the next version of a Process on the machine=


.0pt'> style=3D'font-weight:bold'>Q:  pan>Is
process recycling really required like asp.net.

.0pt'> style=3D'font-weight:bold'>Chris:Â
We've done a ton of work on fixing internal mistakes and fault injec=
testing, etc, and we expect it to work given the Yukon work that is being d=


.0pt'> style=3D'font-weight:bold'>Q:  pan>Have
you considered how you can get OS VM and GC to communicate?

.0pt'> style=3D'font-weight:bold'>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. style=3D'mso-spacerun:yes'>  In XP there is a new low memory notifi=
service.  Finalizer thread in 1.1+=
uses this to also back down.  Futu=
directions should include the CLR being able to get a "budget" fr=
the OS, and then the OS could guarantee that without paging and CLR could a=
tune within that limit.


.0pt'> style=3D'font-weight:bold'>Q:  pan>Do
you have dynamic code gen limitations that would allow things like writing =
for an edit box, etc, like Smalltalk has.

.0pt'> style=3D'font-weight:bold'>George:Â
We are introducing lightweight codegen; not as rich as what was in
Smalltalk, but the tool (aka VS) could help this. style=3D'mso-spacerun:yes'>  No fundamental restrictions.

.0pt'> style=3D'font-weight:bold'>Jim:Â
Less than restrictions, the bigger issue is integrating every feature
across the engine in the right way, such as including security,etc.

.0pt'> style=3D'font-weight:bold'>Anders/et al: yes'>Â
Facilities do exist for compiling up code on the fly, like Reflection
Emit, etc.


.0pt'> style=3D'font-weight:bold'>Q:  pan>Will
ability to add fields via Edit & continue be allowed in managed emit co=

.0pt'> style=3D'font-weight:bold'>Sean:Â
Currently only allowed through unmanaged api's, where support
exists.  We've talked about various
options like this, but have not committed to any immediate plan.


.0pt'> style=3D'font-weight:bold'>Q:  pan>What
kind of safety features do you have around hosting multiple pieces of user

.0pt'> style=3D'font-weight:bold'>Jim:  <=
app domains to provide CAS security around specific to each domain.

.0pt'> style=3D'font-weight:bold'>Brad:Â
Examples are like wsdl parsing and hosting.

.0pt'> style=3D'font-weight:bold'>Patrick:=
Reflection Emit permission is highly privileged.


.0pt'> style=3D'font-weight:bold'>Q:Â
SyncBlock pointer is used for edit & continue, what are you doing
with it?

.0pt'> style=3D'font-weight:bold'>Patrick:=
SyncBlock is actually the "Kitchen Sink Block"
<laughs>.  It's a general pu=
field for lot's of things including locking algorithms, COM interface plumb=
etc.  Dynamically allocated as req=
to get going.  We optimize for loc=
k and
hash because they are the most common case.


.0pt'> style=3D'font-weight:bold'>C:Â
Thanks to Chris for an excellent blog <applause>

.0pt'> style=3D'font-weight:bold'>Q:Â
Transparent proxy work/interception, what about limitations?

.0pt'> style=3D'font-weight:bold'>Chris:Â
We intended for more than remoting, but haven't done a ton with it
beyond that.  Interception is very
interesting; lot's of options.  Co=
uld do
code rewriting using prolog method hooks, etc. es'>Â
Appealing because it is more performance, transparent, and less risky
wrt being bypassed.  Conceptually =
very simple, but digging through details is very complicated (eg: integrati=
with ngen is tough since everyone shares the same copy, and do you want to
impact perf for everyone).

.0pt'> style=3D'font-weight:bold'>George:Â
Pay as you go is very important. Considering heavy inlining and how =
would intercept that without a perf penalty.


.0pt'> style=3D'font-weight:bold'>Q:Â
AppDomains:  currently cann=
unload assembly without unloading app domain. s'>Â
We are dynamically generating assemblies, and do not want to unload =
domains.  Why can't we unload asse=
from an app domain?

.0pt'> style=3D'font-weight:bold'>Sean:Â
Very common request.  We ha=
ve to
hit a higher bar for secure and reliable programming environment. style=3D'mso-spacerun:yes'>  In managed, you have to make sure no o=
ne is
still referencing an assembly, where if it were unloaded you could introduce
AV's or security.  To solve requir=
a  ton of bookkeeping, and you win=
d up
wrapping an assembly with an app domain <stack fault> . style=3D'mso-spacerun:yes'>  Instead, we're looking at making app d=
more performant to use.

.0pt'> style=3D'font-weight:bold'>Patrick:=
There are other systems that can unload code. style=3D'mso-spacerun:yes'>  However unloading is not free of seman=
difficulties.  When you unload, yo=
u must
make sure you have no dangling references.=
You have to define a shut down policy, and that can introduce bad cy=
on shutdown.  These kinds of bugs =
very frequent.  I've implemented t=
before, and it is very problematic and not without bugs. style=3D'mso-spacerun:yes'>  We have a good story on app domains. pan
style=3D'mso-spacerun:yes'>  If we can make it cheaper to get in/ou=
t of
app domains, then this is the best container for code.

.0pt'> style=3D'font-weight:bold'>Jim:Â
I've worked on systems where we used GC to collect code. style=3D'mso-spacerun:yes'>  You fix perf issues, but then you add =
bookkeeping again.

.0pt'> style=3D'font-weight:bold'>Sean:Â
You still have the cycle problem.Â
If one person holds onto an instance of an assembly which holds onto=
other (a->b, b->a), you never get to unload reliably.

.0pt'> style=3D'font-weight:bold'>Jim:  <=
system had to build stuff into the GC to fix this, "it wasn't a pretty
site", not recommended.

.0pt'> style=3D'font-weight:bold'>George/Jim: s'>Â
Security, performance, features.Â
Lot's of trade offs.


.0pt'> style=3D'font-weight:bold'>Q:  pan>Why
do I have to check if a delegate is null before I use it, why isn't there
language support for this?

.0pt'> style=3D'font-weight:bold'>Anders:Â
Requested often, spent fair amount of time trying to figure out a ok
way.  The suggestion doesn't work =
for delegates which return values, etc.Â
Putting this kind thing "ages" the languages when you add
kludges to help solve minor confusion.Â
In the end, decided to leave things be. es'>Â
If we had a chance to do it over we might have done something
differently, but solution suggested is no better than the problem.


.0pt'> style=3D'font-weight:bold'>Q:  pan>Is
there any plans to given an app domain a CPU budget?

.0pt'> style=3D'font-weight:bold'>Chris:Â
Common request in & out of company from folks writing server
code.  Folks want quotas around CP=
U or
memory consumption, etc.  Would be=
to do something here, but instead of quotas, we may track resource usage
instead.  We would accumulate your
"charge account" of things you use, and then put the burden back =
the sophisticated host app to make decisions. s'>Â
That way they can apply their policy directly. style=3D'mso-spacerun:yes'>  Another common request is trying to tr=
memory used by a particular request (say web page compile, sproc, etc). style=3D'mso-spacerun:yes'>  Very difficult thing to track.

.0pt'> style=3D'font-weight:bold'>Jim:Â
Also consider how you would interact with the OS scheduler. style=3D'mso-spacerun:yes'>  The scheduler doesn't give you any hoo=
ks to
integrate closer.  Would be good i=
n the
future to see if we could exploit this.


.0pt'> style=3D'font-weight:bold'>Q:  pan>How
much do you consider other platforms in the CLI design.

.0pt'> style=3D'font-weight:bold'>Jim:Â
when I first joined we were actively developing for multiple
platforms.  Doing this kept us rea=
honest, and standards process helped a lot more. style=3D'mso-spacerun:yes'>  We also have the .NET Compact Framewor=
k which
can also helps.  There are other s=
one could "possibly, possibly consider" <chuckles>. style=3D'mso-spacerun:yes'>  We also released Rotor which runs on s=
other platforms and chips which also keeps us honest. style=3D'mso-spacerun:yes'>  The Rotor team is now part of the CLR =
and those builds are part of our build process.

.0pt'> style=3D'font-weight:bold'>Patrick:=
Example of tension:  in ecm=
a we
tried to get a very specific memory model, but we realized that nobody would
code to it [jlz: advanced chips like ia64 allow for reordering of reads and
writes and let you do scheduling as a code generator; x86 is pretty simple =
less flexible, but simpler and easier], because it is really complicated and
most people target x86 which has much simpler semantics. style=3D'mso-spacerun:yes'>  It's an example where the issues are so
sublte, that even though the architecture could have been more generic, we =
it to be stable across x86, ia64, amd64, etc. s'>Â
Don't test on x86 and deploy on ia64 and have it broken.

.0pt'> style=3D'font-weight:bold'>Jim:Â
show of hands: how many of you have volatile in the right place? style=3D'mso-spacerun:yes'>  This is required for a reordering
architecture, and people don't understand it.

.0pt'> style=3D'font-weight:bold'>Jim/Patrick: es'>Â
Java has tried to be inclusive here, but found themselves in a quagm=
very hard to get right.  We decide=
d to
simplify instead.

.0pt'> style=3D'font-weight:bold'>Sean/Chris: s'>Â
We try to keep complications under the hood for this kind of thing.<=


.0pt'> style=3D'font-weight:bold'>Q:  pan>Any
plans for things like aspect oriented programming and related techniques? p>

.0pt'> style=3D'font-weight:bold'>Chris:Â
We view this as something you could do with interception, if you wan=

.0pt'> style=3D'font-weight:bold'>Anders:Â
Programming by contract is something we've looked at a lot. style=3D'mso-spacerun:yes'>  MSR has done a lot of work here. style=3D'mso-spacerun:yes'>  In the end we decided it wasn't quite =
yet, and so we have abstained here.  an>If
we did aything like this, the solution must allow me to remove up front if =
checks for entry conditions.  To b=
e truly
viable, you need to have it in the CLR/CLS instead of just a language. style=3D'mso-spacerun:yes'> 
Must be through the libraries as well.=
style=3D'mso-spacerun:yes'>  We're not there yet.

.0pt'> style=3D'font-weight:bold'>Anders:Â=
wrt AOP, it seems ok for debugging and monitoring. style=3D'mso-spacerun:yes'>  But the notion you can inject code any=
makes it impossible to understand what your code will do. style=3D'mso-spacerun:yes'>  Unless you have an IDE that can show y=
ou the
"aspect weaving" you won't know what is happening. style=3D'mso-spacerun:yes'>  At this point I'm in wait and see mode=
someone can show large scale successes.

.0pt'> style=3D'font-weight:bold'>Jim:Â
<Plug for Rotor>  des=
ign by
contract is one of the RFP projects that we funded. style=3D'mso-spacerun:yes'>  We are looking at the results of that =
to see
if it is ready for prime time.  Gr=
egor is
a close friend of mine and I reviewed it 8 years ago: there are two halfs to
this problem:  (1) weaving, and (2)
projecting.  As an engineer I need=
look at all the code I will run.  =
I have
a degree in MIT, and you don't just do engineering by combining a bunch of
things and adding them up without understanding how it works. style=3D'mso-spacerun:yes'>  If you look at the union as the requir=
you could have come up with a better solution. I think the community is vee=
in the wrong direction; neither I or Gregor have been able to get them off =


.0pt'> style=3D'font-weight:bold'>Q:  pan>Do
you provide any utilities around lock ordering and dead lock detections.

.0pt'> style=3D'font-weight:bold'>Chris:Â
prior to Whidbey, the locks you take are your responsibility. style=3D'mso-spacerun:yes'>  There is no leveling notions or anythi=
ng like
that.  You get essentially a criti=
section and you can hang yourself with it.=
In Whidbey, with integration with SQL Server, they wanted to do dead=
detection and understand the lock graphs [jlz: the hierarchy of locks where
cycles can come from].  This is st=
rocket science, for most people you should still take responsibility for lo=

.0pt'> style=3D'font-weight:bold'>Q2:  span>I'd
like to do this in C# directly.

.0pt'> style=3D'font-weight:bold'>Anders:Â
You should take advantage of the u=

statement.  We may not have put th=
e style=3D'font-style:italic'>lock keyword in if tyle:
had proceeded it.


.0pt'> style=3D'font-weight:bold'>Q:  pan>In
new C++, determinsitc finalization is there. '>Â
What about other languages?

.0pt'> style=3D'font-weight:bold'>George:Â
they've provided scope destructors, not really deterministic behavior
per se.  If the scope goes away, y=
get the dispose, but you can still make mistakes. style=3D'mso-spacerun:yes'>  What people usually mean here is they =
want to
solve the whole thing, and this doesn't do that. style=3D'mso-spacerun:yes'>  It is still useful. style=3D'mso-spacerun:yes'>  But it isn't the silver bullet.

.0pt'> style=3D'font-weight:bold'>Anders:Â
important to understand the syntax is really no more expressive than=
using statement in C#. style=3D'mso-spacerun:yes'>  The new pattern comes with some restri=
on patterns that using doesn't
have.  For example, you have to de=
vars in a separate scope instead of inline.
Agree with George that this is not deterministic finalization.

.0pt'> style=3D'font-weight:bold'>Patrick:=
Absolute lifetime we looked at, and keep looking at it, but it is
really, really expensive.  You hav=
e to do
micro-management.  You have to pro=
ject to
all processors the state, which doesn't scale well. style=3D'mso-spacerun:yes'>  There are tricks, but so far cost >
benefit.  We don't believe in gene=
people want to do micro-management, instead they want good enough guarantees
that you don't leak and you want limit of population of some resources to a
finite number [jlz: like a pool with a quota enforced]. style=3D'mso-spacerun:yes'>  HandleCollector is a good new example =
we are providing this kind of functionality. '>Â
AddMemoryPressure is also another good example that allows you to he=
tune the GC (good for cases like allocating bitmaps, where managed side hol=
class is very small, but unmanaged memory hit of the resource could be huge=

.0pt'> style=3D'font-weight:bold'>Q2:  span>My
problem is less about memory but the resources [jlz: like database handles,
expensive files, etc].

.0pt'> style=3D'font-weight:bold'>George/Patrick: n:yes'>Â
but that is what Finalization is.

.0pt'> style=3D'font-weight:bold'>Jim:  <=
language provides this from using =
this is the right way to solve this problem.


.0pt'> style=3D'font-weight:bold'>Q:  pan>Love
integration idea with the OS.  But=
are you going to accomplish that in the long term? style=3D'mso-spacerun:yes'> 
Eg: wait for Moore's law to help, vide=
o card
processing [jlz:  GPU's are incred=
good at bit vectors schemes].  Or =
something like an IL machine ala Transmeta.

.0pt'> style=3D'font-weight:bold'>Patrick:=
Our codegen is pretty good, and getting much better (eg: dynamic and
static profiling).  The OS can use=
so we are on track and efficiency is not the key issue. style=3D'mso-spacerun:yes'>  The real problem is right now we don't=
the entire range of services so you have to p/invoke. style=3D'mso-spacerun:yes'>  Msft needs to provide a complete range=
these api's so that don't need this and Win32 can go away. style=3D'mso-spacerun:yes'>  My dream is after Longhorn you could d=
o this,
removing longhorn p/invoke statements.

.0pt'> style=3D'font-weight:bold'>Patrick:=
We actuallly are thinking the opposite of IL machine. style=3D'mso-spacerun:yes'>  I did chip design at TI for lisp
machines.  The competitor was 6x s=
than ours to run the same applications.Â
You get better if we program to IL, and then let the JIT optimize for
the specific hardware where you can take advantage of subtle advantages in =
specific chip.  Several manufactur=
es are
serious about adding advanced features along these lines. style=3D'mso-spacerun:yes'>  With our pluggable optimizing codegen,=
we can
do great on the fly generation this way.

.0pt'> style=3D'font-weight:bold'>Jim:  <=
was the PhD advisor for the chief designer at Transmeta. style=3D'mso-spacerun:yes'> 
His general comment was using IL as it=
is not efficient.  We should look =
at something like mips where you look for common codegen patterns from
compilers and make those go fast.Â
Example is optimizing interface dispatch code pattern.


.0pt'> style=3D'font-weight:bold'>Q:Â
Threading: do you have intent to write a scheduler in the CLR, for
example, something that could work with fiber mode.

.0pt'> style=3D'font-weight:bold'>Chris:Â
In Whidbey we did a lot of work to integrate the CLR into SQL
Server.  Prior to this we also sch=
on pre-emptively OS scheduled threads.Â
But we knew we might change this, so System.Thread isn't semantically
locked this way.  In Whidbey, a
sophisticated host can integrate and target fiber code. style=3D'mso-spacerun:yes'>  We support this. style=3D'mso-spacerun:yes'>  With a small box, normal thread mode is
fine.  If you have very large mach=
(eg: 32-way), then it might give you value.
The hosting api's do allow you to integrate your own scheduler around
fibers just like SQL.  Having said=
that, I encourage you to stay away from it <laughs> style=3D'mso-spacerun:yes'>  The benefits are just getting smaller =
and it
is very hard to use and do correctly.

.0pt'> style=3D'font-weight:bold'>Patrick:=
the OS is making lot's of progress closing the gap here, and its val=
is becoming less with every new release.

.0pt'> style=3D'font-weight:bold'>Chris:Â
If we could get to the pure managed world Patrick was dreaming of, w=
we don't know when/if we could ever get there, that we will be able to smoo=
out the rough edges of this kind of programming style. style=3D'mso-spacerun:yes'>  We could smooth async model and
marshalling,etc.  It will be a lon=
g time
before we could do this.


.0pt'> style=3D'font-weight:bold'>Q:Â
Extremely difficult to write a generic library that is exception
safe.  Wouldn't it be nice if at c=
time you verify code was exception safe.

.0pt'> style=3D'font-weight:bold'>Anders:Â
Commonly asked for, not specifically related to generics. style=3D'mso-spacerun:yes'>  I don't know of a solution that doesn't
simply exchange one set of problems for another set. style=3D'mso-spacerun:yes'>  There is the Java solution where you c=
declare what you've thrown and require caller to handle or push out
further.  There are some serious
scalability problems with this model; you have to compute the closure which
winds up making people go to catch(…) which is no good.. style=3D'mso-spacerun:yes'>  It also has the versioning problem, wh=
ere you
can't add new exceptions in future versions without breaking the already
written clients.

.0pt'> style=3D'font-weight:bold'>Anders:Â
what would probably be better is an Fxcop style checking, and we cou=
do a better job on documentation.

.0pt'> style=3D'font-weight:bold'>Q2:  span>I
understand why you didn't do the Java solution; I don't like it either. style=3D'mso-spacerun:yes'> 
But couldn't you do something around g=
because it is very difficult to do otherwise.

.0pt'> style=3D'font-weight:bold'>Anders:Â
I'm not sure I see the connection between generics and exceptions. p>


.0pt'> style=3D'font-weight:bold'>Q:  pan>There
are lot's of type systems now, do you see any chance of integration (eg: CLR
& XML).

.0pt'> style=3D'font-weight:bold'>Anders:Â
There are differences and we keep whittling away the differences. an
style=3D'mso-spacerun:yes'>  If you look at XAML you can extend with
tags/attributes that map to class and language elements. style=3D'mso-spacerun:yes'>  It's true that XSD dreams up extra stu=
ff that
doesn't map well.  It was design by
committee effort so you see things that don't necessarily see use in real l=
ife. style=3D'mso-spacerun:yes'>  We're working towards equilibrium here=


.0pt'> style=3D'font-weight:bold'>Q:  pan>Any
reason the Reflection API's didn't support reflecting on the IL?

.0pt'> style=3D'font-weight:bold'>Jim:  <=
reason at all, we ran out of time <laughs>.




with Microsoft Office OneNote 2003

One place for all your notes

Skip to main content