|
From: Diane M <dia...@gm...> - 2017-09-01 13:51:11
|
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 > |