We optimally cache a lot of the JIT metadata we collect, for things like e.g. loop entry points from #8 or which control flows merge from #7 or DWARF abi information from #3.
All of this data should be identical across runs with the same binary. So hypothetically we should be able to not only cache the data for one run, but all future runs of the JIT.
We should look into dropping the data to disk, and mmapping it back in when we start back up again to have the best information we can, and atomically updating the database if we get new information in a run.
Slight problems are we have to handle cache invalidation if the binary is updated, or any data that depended on a symbol from a dynamic library that was updated.
We optimally cache a lot of the JIT metadata we collect, for things like e.g. loop entry points from #8 or which control flows merge from #7 or DWARF abi information from #3.
All of this data should be identical across runs with the same binary. So hypothetically we should be able to not only cache the data for one run, but all future runs of the JIT.
We should look into dropping the data to disk, and mmapping it back in when we start back up again to have the best information we can, and atomically updating the database if we get new information in a run.
Slight problems are we have to handle cache invalidation if the binary is updated, or any data that depended on a symbol from a dynamic library that was updated.