|
From: Diane M <dia...@gm...> - 2017-09-01 13:52:42
|
Forgot to mention that we might be able to look up code in a cache using offsets from function symbols, rather than addresses... I still don't think this will be faster though. Diane On Fri, Sep 1, 2017 at 9:50 AM, Diane M <dia...@gm...> wrote: > Julian, > > Somehow this message wound up in my spam folder. This is a very > interesting thread. > Please see my comments below. > > On Thu, Aug 31, 2017 at 4:25 AM, Julian Seward <js...@ac...> wrote: > >> >> > > If you are considering translating the entire program and caching it, I >> > think that would be much faster, >> >> Mhm, but then you have the problem of finding all the code that is part of >> the program, which is equivalent to solving the halting problem. >> > > It depends how you go about it. Oracle's Discover does this, but it > depends upon annotations inserted > by the Studio compilers to tell it where functions start and end, when > things in the .text section are > actually not code, etc. So Discover is function-based, and Valgrind is > code block-based. Obviously > the latter is much more robust, but unfortunately, slower. > >> >> ----- >> >> For these reasons, my preference is to make the JIT faster, and ultimately >> to move to having a "two speed" JIT. That is, where code initially is >> instrumented using a fast and low quality JIT, to reduce latency and to >> gather branch and block-use statistics. When we decide a particular path >> is hot enough then those blocks are given to a slower, optimising JIT, so >> we ultimately get both low latency for cold paths and high performance for >> hot paths. This seems to be the "modern way". >> >> Also, the optimising JIT can run in a helper thread, so in effect we never >> have to wait for it, because we can just use the unoptimised version of >> a (super)block until the optimised version is ready. >> > > Those optimizing JITs can take a very long time, but I like the idea of > using the slower code while > waiting for the faster code to be optimized by a separate thread. Though > there are issues with > doing that also having to do with maintaining correct program state when > switching between the two. > > Diane > > >> >> J >> > > |