To start, you don't have to do it that way. You can use sampling based profiling so that there is no training set necessary: http://dl.acm.org/citation.cfm?id=2854044

Past that, LLVM is already like this, it's just a matter of shipping bitcode, and outputting the currently optimized bitcode at shutdown.

It is actually done in practice, but admittedly, only by those who care tremendously about performance.

(IE you don't find it done in common linux distros).

Particularly in a datacenter world, where you have hypervisors and things under the covers anyway, it's not a huge deal to have a JIT running.

The harder part is actually, if you are a cloud provider, getting anyone to bring bitcode with them :)

Even if you promise them X% performance gain to start, where X is usually 10-30%, they don't usually care enough to modify their workflow.

> Has any C compiler closed the loop on that by shipping the full compiler with the program to do runtime optimization?

- The truffleruby "cext" project demonstrated something like this. They interpret and then JIT C on the JVM, and do cross-language inlining and other optimizations.

http://chrisseaton.com/rubytruffle/cext/

The same group is working on compiling LLVM IR on the JVM. Presumably the JVM's tiered runtime optimizations would apply to both of these.

https://github.com/graalvm/sulong

- There are also interactive C(++) "JITs" from CERN and the Julia project. However, as far as I know, they are both method JITs and don't do any trace-based re-JIT/OSR.

https://root.cern.ch/cling and https://github.com/Keno/Cxx.jl

Google has this in production. According to https://research.google.com/pubs/pub45290.html AutoFDO is deployed to hundreds of binaries at Google. Over half of CPU cycles used are now spent in some flavor of FDO-optimized binaries. And that was in 2016.

HP's Dynamo did something comparable in 2000:

http://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-1....

The non-trivial part is that most optimization are contextual and not "one function at a time". Re-optimizing only a single function may not even be possible/useful with things like partial inlining/outlining, etc.

Well, a JIT will add overhead that will defeat the purpose of using C in the first place.

If you start with optimized code from the AOT compiler, and do sampling based profiling every so often, the overhead is miniscule The only time it would probably be a net lose is when you have a very large number of short lived executions.

Okay, and if you manage to show that it's feasible in practice, I am sure people would adopt such an approach.

Err, people already do it, but you are probably not going to see widespread adoption anytime soon no matter what. Until nobody has to think about it, nothing changes