In that case, it seems we have a different metric for a JIT compiler being "better"? I was going by the quality of the final output, but you seem to be going by the complexity of the intermediate optimizations it goes through? Which I admit also makes sense, but it's not what I expected: when someone says "is X better than Y", the obvious implication is they should choose X over Y since it would yield a better result, and yet that generally wouldn't be the case here?

Think about it like this:

Two chefs.

Chef A gets really easy to use ingredients and produces a good dish with them.

Chef B gets rubbish ingredients but spends time doing amazing techniques with them anyway and produces a good dish as well, maybe even a bit better!

If this is all we know about the chefs, I'd say it looks like Chef B is the 'better' chef. It's not their fault they got worse ingredients, and they managed to do a great job with them.

You didn't need Chef B to handle Chef A's ingredients, because they were simple. Perhaps we should thank the supplier for that! But Chef B is still the 'better' chef.

It still might be nice if Chef A could do some of the amazing techniques that Chef B did, even though their ingredients mean they aren't required all of the time. They may help in some cases.

The .NET CLR JIT is Chef A, the JVM's HotSpot C2 JIT is Chef B.

I mean if we judge a JIT just by the quality of the output and don't consider the input, then reducing to absurdity an identity JIT for already-optimised machine code to the same machine code is the best JIT in the world. Clearly it isn't.

What you say would make sense in a hypothetical world where every JITter could work with every language, but that's not the world we live in. You can just hand chef B better-quality ingredients and have him do his thing, but you can't just hand HotSpot MSIL code and have it do its thing. Half of this is due to differences in the representations. The other half is because MSIL has features that (as far as I know; please correct me if I'm wrong) the JVM doesn't have, such as by-ref variables, which it would still need to support, but which might make optimizations such as escape analysis harder.

This is why people judge chefs independently from the ingredients they are given, but don't judge languages and implementations independently from each other. In the first case they are actually (mostly) independent in the real world, whereas in the second case they are frequently dependent on each other, and it is not possible to mix-and-match languages with compilers. (But I certainly do hope we get to a point where the latter would be possible, too.)

Your points do make sense.

I would argue that it just isn't the case in practice that MSIL includes anything that would make optimisations that the JVM does significantly harder, but I only have my academic and professional experience working on both systems, nothing that I can cite or prove to you.

Is it not that Chef B doesn't have a frying pan (i.e. decent generics) so has to do a lot of tricks?

Thanks for this analogy, I love it!!