Doug S (foo.delete@this.bar.bar) on June 23, 2020 2:04 am wrote:
> Mark Roulo (nothanks.delete@this.xxx.com) on June 22, 2020 7:38 pm wrote:
> > Doug S (foo.delete@this.bar.bar) on June 22, 2020 6:14 pm wrote:
> > > anon (anon.delete@this.anon.com) on June 22, 2020 4:22 pm wrote:
> > > > They're doing hybrid: both JIT/dynamic and install time
> > >
> > >
> > > They would have to, as there would be some applications or at least parts of them (any sort
> > > of generated or self-modifying code, Linus' example of applications that fiddle with the
> > > signal stack, and other such niche cases) where static translation isn't feasible.
> > >
> > > Though I wonder if a combination of both in the same application
> > > is even possible. Maybe it is all or nothing,
> > > either the static translator is able to do the job but when it can't it goes full JIT for that application.
> > >
> > > Maybe they've found a way to slide neatly between the two by maintaining enough "x86 state"
> > > in the translated binary to let the JIT cut in where necessary, but that sounds like it might
> > > be MUCH harder than static translation alone, which is already much harder than JIT. There
> > > are a lot of devils hidden in the details that will be interesting to find out more about.
> >
> > How would the static compiler know if the application it was translating was going to generate object code?
> >
> > I think the translator would have to support both or only JIT translation.
>
>
> A jump to an address where the static translator doesn't see a reachable code section.

Consider the case where an application loads a DLL by name. Do we statically compile each half if possible, but are prepared to jit the other bits if necessary?