What is the unit of hotness?

[eqrion]

In the compilation_order section:

* hotness |U32| defining how often this function is called

It sounds like a goal is to have the hints be concrete facts about program execution, so it would be nice to have a unit for interpreting this.

What if we said that 'hotness' was instead a 'call count' which describes how many times in the 'average program execution' a function was executed? A value of '0' would indicate very cold code that is a candidate for lazy execution. A value of '1' would indicate run once initialization code. Values greater than '1' could then be directly compared against an engines existing tier-up heuristics to see if it's worth eagerly compiling a function.

If you went this route, you could also rename the 'compilation order' field to 'call order' which similarly indicates which order functions execute in an 'average program execution'. The interpretation would be the same as specified though, just a different name.

[ecmziegler]

As discussed in the in-person meeting it would be desirable to have a clear definition of hotness. It might not be required for every engine as they might just tier-up in descending order of hotness until a given budget is exceeded. but it would certainly help to make the information more usable and allow other strategies.

I tried to avoid using absolute numbers, so we might use a fraction here instead. This could be divided by the number of function calls in total or be the probability to find this function on top of the stack at any given point in time. What I like about the absolute number though is that we can specify functions that only run once. It's not easy to distinguish function only called once during initialization from functions that were by chance called once. So perhaps, this should be encoded independently.

I like the idea of renaming the compilation order to call order as it's easier to understand and highlights that we collect information on the module and not take decisions on what the engine should do with that information.

[eqrion]

I tried to avoid using absolute numbers, so we might use a fraction here instead. This could be divided by the number of function calls in total or be the probability to find this function on top of the stack at any given point in time. What I like about the absolute number though is that we can specify functions that only run once. It's not easy to distinguish function only called once during initialization from functions that were by chance called once. So perhaps, this should be encoded independently.

Why have you tried to avoid absolute numbers? They seem like a good fit here, but I might be missing something.

[ecmziegler]

To be honest, we are using absolute numbers in V8 and it would be much easier to standardize this :)

The problem is what the interpretation of what's high and what's low depends on other factors. In V8, we know when we tier up and therefore stop collecting additional call counts. This makes these absolute numbers useful for us, because we know what's "high" and what isn't. Other engines but tier up sooner or later. Later might not be a problem because if a function gets enough call counts, even on a longer run, it might be worth tiering it up. However, if tier up is sooner, then we might miss out on important functions because the numbers look low to us. That is in case the data is collected by an actual engine at runtime without any additional profiling which is an option I would like to keep.

If an explicit profiling run with additional instrumentation (that might be active for longer) or sampling is used, absolute numbers depend on how long that run was.

I therefore preface relative numbers that each engine/profiler can normalize based on the information they have.