Currently, turning on the command-line timing profiler wraps all method objects in the system with a timing wrapper. This work well enough, but by being in the call path it tends to interfere with optimization, changing the execution behavior of the code under profile.

There's a few ways we could improve this:

• Call sites could contain the logic necessary for profiling. Rather than wrapping the target method, we'd just use a different call site. This would also fit into invokedynamic mode, allowing us to patch profiling into the call chain without breaking optimization and inlining.
• We could switch all dispatch to use invokedynamic call sites and do the same instrumentation above
• We could force code to JIT immediately, allowing more use of JVM profiling features. This does have the down side that unjittable code would not profile the same way.

In any case, I'd like to see us get a little more creative about how to inject profiling into an application without changing how it optimizes as much as we do now.