On Tue, Jul 30, 2013 at 3:20 PM, Jonathan S. Shapiro <[email protected]>wrote:
> The example that you gave is fine, and subject to your assumptions above, > I think that what you say is feasible. But note that JIT compilation > effectively *is* whole program compilation! > That is a funny wrinkle of terms. I think we need to draw a distinction between C++ like whole-program-source-code compilation, which can't be reliably repeated on end-systems, and run-time bind specialization, which can. As long as we can deliver new versions of DLLs, I don't much care what the runtime does. > What am I missing? >> > > What I think is missing here is that you're using a very big, complicated, > unsafe system (the JIT compiler) to implement an allegedly safe program. > The JIT system itself is part of the attack surface of every application > (as Google has found out the hard way). > > A static compiler isn't necessarily simpler, but operates under less > performance pressure, and therefore has more freedom to keep track of types > as it works. > I thought in bitc-the-first you gave up on static compilation because of the FBC unknowable fields offset problem. When you say static compilation, are you talking about static on-target-machine ahead-of-time compilation (like CLR AOT)? I've long accepted JIT as an essential part of any solution, since there are too many dynamisms we pay unreasonable performance costs for without it. Figuring out how to write safer JITs sounds like an interesting topic.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
