 CLR Panel notes
started 10/30/2003; 11:51:04 AM - last post 11/1/2003; 9:07:07 AM
|
|
Ehud Lamm - CLR Panel notes 
10/30/2003; 11:51:04 AM (reads: 9999, responses: 6)
|
|
| CLR Panel notes |
|
The 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. The Panel was swamped with standing room only folks at the end (about 40 up around the stage with lot's of questions). At the panel we had Brad Abrams (CLR BCL PM), 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 Jonathan Hawkins (CLR PM/Moderator).
It's PDC week, you know... So don't be alarmed: Haskell and such will return shortly.
Some interesting stuff regarding the memory model, support for AOP, and contracts.
Posted to cross-language-runtimes by Ehud Lamm on 10/30/03; 11:52:55 AM
|
|
|
|
Patrick Logan - Re: CLR Panel notes
10/30/2003; 5:23:02 PM (reads: 480, responses: 0)
|
|
|
We are introducing lightweight codegen; not as rich as what was in Smalltalk...
Funny how this statement about Smalltalk is phrased in the past tense.
|
|
Isaac Gouy - Re: CLR Panel notes
10/31/2003; 8:14:52 AM (reads: 415, responses: 0)
|
|
|
In the question, Smalltalk was used in the present tense.
In his answer, George Bosworth used the past tense - his present and future is CLR, his past was Digitalk Smalltalk VM design.
|
|
Chris Rathman - Re: CLR Panel notes
10/31/2003; 8:25:35 AM (reads: 408, responses: 0)
|
|
Funny how this statement about Smalltalk is phrased in the past tense. Perhaps they mean that it is a feature that has since been removed from Smalltalk?
|
|
Patrick Logan - Re: CLR Panel notes
10/31/2003; 9:40:45 AM (reads: 388, responses: 0)
|
|
|
Less than restrictions, the bigger issue is integrating every
feature across the engine in the right way, such as including
security, etc.
I don't believe that security (of this complexity) has to be addressed for all these features at the virtual machine level *if* the virtual machine designers do not insist on implementing all these features in the virtual machine!
What are the essential security features of a virtual machine?
Essentially accessing machine-level resources in controlled ways, e.g.
via capabilities. There should only be a small set of resources at the
virtual machine level, everything else should be at a higher level, e.g. if your process has the capability to communicate with certain other processes, they can grant your process some of their capabilities.
The small set of lower level resources would include things like
allocating certain amounts of isolated memory, running certain durations of time, starting other processes, and communicating to other processes.
What other security features should be at the virtual machine level?
|
|
Patrick Logan - Re: CLR Panel notes
10/31/2003; 9:43:20 AM (reads: 391, responses: 0)
|
|
|
In his answer, George Bosworth used the past tense - his present and future is CLR, his past was Digitalk Smalltalk VM design.
Ah, OK. I thought I recognized the name but I could not put my finger on it.
|
|
|
|
|
Jim seems to be unsure of himself:
"Gregor is a close friend of mine..."
"I have a degree in MIT, and ..."
"I was the PhD advisor for the chief designer at Transmeta."
BTW what are the "prolog method hooks" referred to by Chris:
"Chris: ...Could do code rewriting using prolog method hooks, etc."
|
|
|
|