2

I have been profiling a lot of javascript today in writing a firefox js engine bug report, and started really noticing the slight differences between JIT compilations.

While there are some obvious things that could cause non-deterministic flagging of "hot" sections of code (for example, inlining or not inlining a function that is called a random number of times), I was wondering if external fluctuations of execution speed (like CPU throttling) could cause non-deterministic JIT compilation?

  • That's unlikely. The jitter doesn't know how many clock cycles per second it is receiving from the processor, and it probably doesn't matter anyway. The job of the jitter is to optimize the code performance relative to other possible code implementations, not to race the clock. – Robert Harvey Oct 7 '15 at 5:53
  • "probably doesn't matter anyway". So hypothetical highly fluctuating clock cycles would not effect the jitter? I don't quite understand. – Burdock Oct 7 '15 at 6:02
  • 1
    @RobertHarvey: that depends on the JIT, really. I remember that one iteration of Internet Explorer (9? 10? I forgot.) had a completely new JIT architecture with the JIT running on a background thread. The interpreter and the JIT would both start processing the same AST immediately, and whether or not a specific function was executed compiled or interpreted, depended on whether the JIT had managed to "overtake" the interpreter yet. – Jörg W Mittag Oct 7 '15 at 10:09
  • When you say "called a random number of times," do you mean the compiler is compiling differently based on the number of calls in the source? Does it always compile the same way with the same number of calls? If both of those are true, you're getting deterministic results. – Blrfl Oct 7 '15 at 10:32
  • @burdock: Any given optimization is always going to take the same number of clock cycles, no matter how fast or slow the processor is running. – Robert Harvey Oct 7 '15 at 15:12
6

There are many ways in which JIT compilation can be non-deterministic. For example:

  • if the JIT runs on a separate thread, depending on OS scheduling, during one run, the JIT may be scheduled first, and compile a certain function before it runs, whereas on a different run, the interpreter may be scheduled first, and run the function before it is compiled
  • if the JIT uses dynamic profiling information for optimization, and the profiler is a sampling profiler, then even tiniest fluctuations in timing, memory layout, etc. may cause the sampling to occur at different points of the execution, possibly leading to different results
  • the more aggressive the optimizations, the more CPU time and memory the JIT compiler needs. If the system is low on memory, for example, a JIT compiler may decide to disable some optimizations, or only enable them for a few very high value targets (i.e. very hot spots)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.