On Mon, Oct 5, 2009 at 8:14 PM, William Leslie <[email protected]> wrote: > > 2009/10/6 Jonathan S. Shapiro <[email protected]>: > > Trivial example 1: The "readonly" keyword in C# is (correctly and > > necessarily) ignored by most C# compilers. Exercise for the reader: > > explain why. > Any discussion of optimisation needs to keep in mind the premise that > optimisations are only applicable if they preserve the semantics of > the language. Any attempt to take advantage of readonly would need to > show that, on the domain of interest, no paths modify the region of > interest, and that there are no memory barriers; effect analysis of > this depth is very expensive if all you are getting out of it is to > show that a readonly is a loop invariant...
Ahh. You are forgetting that both the Java and the C# runtime environments have preemptive concurrency. In many interesting cases, the analysis you want simply cannot be done unless you prohibit runtime class loading. > , indeed, if you are doing > that kind of analysis, readonly is redundant. You misunderstand what readonly does. It allows you to state, for example, that a class member field is unchanging. In that situation, it is not at all redundant. > > Yes. They eliminate between 50% and 60% of current vulnerabilities. > > > > But be careful. You need to test and calibrate the runtime cost of this... I am reminded of a humorous comment that Jochen Liedtke once made: "Fast, yah! But correct? Eh." > > JIT code is bad because we don't know how to assure anything as > > complex as a JIT compiler. > > Any transformation a JIT compiler makes must preserve the semantics of > the original program, otherwise it would not be useful. That's a fine statement on paper. And like I said, it is *considerably* beyond the current state of the art to know whether a given JIT compiler actually meets this requirement. > Since the > program must have been shown to be safe to have been compiled the > first time... How do you know that this check was actually performed? shap
