On Tue, Jul 30, 2013 at 4:02 PM, David Jeske <[email protected]> wrote:
> I thought in bitc-the-first you gave up on static compilation because of > the FBC unknowable fields offset problem. > Not entirely. I continue to feel that there is an intermediate position in which the dynamic portion of the compilation looks a lot more like a relocation pass than a JIT pass. > When you say static compilation, are you talking about static > on-target-machine ahead-of-time compilation (like CLR AOT)? > That's another possibility. > 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. > For general applications there are real advantages to JIT systems. Mainly: you get to leverage run-time knowledge to generate code that (in some cases) is much better. One thing I don't have a handle on is the degree to which a system like hotspot can do better than a system like `cc (tick-cc), which produces meta-code at static compile time, e.g. for loop unrolling. It clearly depends on the degree of dynamic dispatch in the language. But as you note, there are confidence concerns with JIT systems. For the moment, I'm happier with installation-time AOT. I'm trying hard to ensure that all parametricity-driven code generation issues are resolvable at the time the application is installed, and that all compile errors that might result from such code generation are known no later than [static] compile time. That's more or less my current line in the sand. That doesn't mean you *have* to do it that way. It doesn't exclude JIT, and it notably doesn't exclude later addition of a module that can be dynamically linked by the application. What it *does* mean is that the set of modules that the application plans to dynamically link may need to be locally registered so that the AOT compiler can generate the needed specializations. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
