[rdc12]

For me the key concept that comes to mind for a JIT compiler, is profiling at runtime to decide what to compile and how aggressively which this article doesn't deal with. The other big thing is how to make the profiling and compilation not be too expensive to negate itself.

The article author seems to be using GCC not at runtime, but more as a generator for templates (at the machine code level) for the rest of the software to use. You don't really want to be assembling a template at runtime in this context.

[MaxBarraclough]

Mixed-mode execution (interpreter+JIT when justified) isn't the only way to go.

.Net doesn't work that way, for instance. Unlike Java's HotSpot, .Net never interprets CIL instructions. They're always compiled down to native code for execution.

At least, that was true in 2009, according to Jon Skeet - https://stackoverflow.com/a/1255832/2307853

[defined]

> .Net never interprets CIL instructions.

I wasn't aware of this. To be clear, it's not 100% accurate to say "never", because it depends on the .NET environment, but point taken.

I now understand that .NET (on desktop, anyway) compiles all intermediate code (CIL) to native code on every run. This is a way different kind of JIT than Java HotSpot, which executes intermediate code (bytecode) initially, profiles intermediate code execution, and only compiles the hot spots to native code after a while.

It seems like what "JIT" means has evolved since the time it meant "JVM HotSpot".

There's a very interesting snippet of an interview with Anders Hejlsberg at https://stackoverflow.com/a/1255828/4158187, which exposes his reasoning.

[MaxBarraclough]

There's a rats' nest of terminology here.

".Net" and "Common Language Runtime" refer specifically to Microsoft's implementation. The spec is called the "Common Language Infrastructure".

Wikipedia seems to use "Common Language Runtime" in both ways - the Mono article uses it in the generic sense, whereas the CLR's own article explicitly states that it refers to .Net's implementation.

.Net also has ngen.exe which isn't really JIT at all, it's traditional 'offline' ahead-of-time compilation. In a sense that's rather like the traditional Unix compile-and-install model. One sees the oxymoron "pre-JIT" used to describe this.

This is another difference from HotSpot, which historically never cached native code to disk, though other JVMs have always been able to do this (Excelsior Jet, and GCJ, for instance).

Apparently AOT may be coming to Java though - it may even already be here, I'm not quite sure.

https://www.infoq.com/news/2016/10/AOT-HotSpot-OpenJDK-9 , http://openjdk.java.net/jeps/295

I recall once reading that one of the reasons HotSpot didn't cache native code, was the issue of securing that cache. Not sure what they've done to address that, nor what .Net does; it seems a valid concern.

That's an interesting read re. Hejlsberg. Worth noting that Mono takes them up on that and does feature an interpreter.

[MaxBarraclough]

Speak of the devil - https://news.ycombinator.com/item?id=15686875

Edit: I'm wrong about the terminology! https://news.ycombinator.com/item?id=15688290