On Tue, Jul 30, 2013 at 5:14 PM, David Jeske <dav...@gmail.com> wrote:
> On Tue, Jul 30, 2013 at 4:16 PM, Jonathan S. Shapiro <s...@eros-os.org>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). > Right. That kind of thing requires more serious optimization. Though we *can * guarantee that the only places where VTable dispatch arises is when explicit instances are used. In practice, that's not a bad position to be in. > 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. > No no. The dynload gets a relocation at dynload time. The only way you can get an offset mismatch is if you have a version mismatch across the subsystems where some object structure changed in a significant way. That's a case where the dynload needs to fail anyway. > 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. > I'm not trying to avoid JIT. I'm trying to start with a lesser requirement that executes faster and is more easily verified. shap
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
