Currently we have use-count metrics that we rely on to decide when we should enter Baseline and IonMonkey. These metrics are not good for reporting to the profiler as these counters are being reset when we fallback. Also, the use-count fails to consider the length of the loops which are being executed. This is ok when there is only a single loop in a function body, but this is not ok when you have multiple loops. For profiling purposes, I suggest to add/change our counters to count the numbers of bytes our interpreter is executing. I suggest to proceed as follow, by adding the number of bytes the current block contains when evaluating a JSOP_JUMPTARGET opcode. Then we can mirror this numbers in both Baseline and IonMonkey. Unfortunately, this might prevent a few IonMonkey optimizations, and therefore slowing it down a bit, but this should not be a big issue. On exceptions, we would have to remove the number of bytes which were not executed from the given counter.