On Tue, Jul 30, 2013 at 4:16 PM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > I see, this is a solution for the field-offsets problem but does not offer the benefits of polymorphic inline caches for virtual methods. (unless you use some previously gathered stats to hint about them, which I suppose is possible). It seems like you are going to paint yourself into a single static run-time bind pass through, forbidding run-time dynload -- because that could trigger an offset mismatch and thus a full relocation, which basically is turning back into JIT. CLR, for example, handles this and will shift data and rewrite code to adjust offsets to make new dynloads match, even if the original load was from AOT. I can imagine that creating some annoying situations... the user might ask to load/save using a codec that triggers an offset mismatch and re-compile/restart, or a web-plugin downloads and has to recompile/restart the browser. I understand your sensibilities here about static AOT, and I don't disagree with them. I guess so far I think there are too many wins of JIT to avoid it.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
