Interpreted and JITted compiled (bytecode) languages?

[SoniEx2]

Would it be possible to have non-machine-code languages, such as Java (JVM bytecode), Lua (LuaJIT bytecode), etc?

(it's also possible to extract JIT output from java but it involves running the program... meh)

[mattgodbolt]

As a matter of policy we have so far not done JITted languages. Most of these languages require you to run a representative data set long enough to "warm up" the JIT to get output comparable to static compile output, and I'd hate for CE to become a "look how bad JITted language output is compared to static compiled".

See also #1058 which I'll opine in too.

[SoniEx2]

This issue is not about JIT output. Granted I did list 2 JITs, but mainly because they're designed to have portable bytecode (LuaJIT broke that with the 64-bit GC recently, but w/e, still mostly portable).

That is, Java bytecode, LuaJIT bytecode, optionally Lua (5.1/5.2/5.3) bytecode (output from luac -l -l -o /dev/null -) on different platforms (x86 vs x86_64), etc.

[mattgodbolt]

Understood! Reopening for that. See also #12

[mejedi]

@SoniEx2 You might like https://github.com/mejedi/luajit.me

[leo60228]

This is a tricky issue. I think the best way to handle this is probably something like for C# have ".NET 5.0" that displays bytecode and "Mono AOT 6.12.0" that displays the assembly generated by mono --aot. The "AOT" should hopefully clarify that it isn't representative of Mono as a whole, and it not being the default should hopefully clarify that it isn't representative of the language as a whole.

While I don't think this is a problem for either Lua or Java, for C# versioning could be a bit tricky. The only major C# compiler is Roslyn. However, from my understanding:

• Roslyn has its own version numbers that I believe are referring to semver for the internal API
• Roslyn's changelog uses Visual Studio version numbers
• Roslyn's releases use .NET version numbers
• Mono and .NET releases come bundled with a Roslyn release

[leo60228]

For C# specifically, Mono has several optimizations that are disabled by default and only recommended for AOT compilation. The documentation says that mono --aot -O=all can lead to "potential better performance" compared to plain mono, but I can't find any benchmarks.

[omern1]

@leo60228 you might be interested in #2592.

[leo60228]

Thanks, I've left a comment there.

[mattgodbolt]

Some thoughts on Java from Discord:

---

So, here's the idea to implement JIT output for Java (openjdk/HotSpot JVM):

1. user types in some java code
2. compile that as right now with javac
3. use javap or some other method to find static methods that return nothing and take no arguments (e.g. static void payload()). Those methods are good targets to get JIT output for.
   • Maybe a separate 'tool' could be added in compiler explorer to get JIT output that has a drop-down with the applicable methods (or something like that).
4. Then, have some internal bit of Java code that loads the payload class/method reflectively, and executes it inside a loop for 20K invocations (this should be enough to get the highest tier of JIT compilation, but there are methods to check that JIT compilation took place as well)
   • The runtime flags needed to make this work correctly are: -Xbatch (block execution while JIT is running, so the loop doesn't finish before we can get the assembly). -XX:CompileCommand=dontinline,package.class::method() this disables inlining of the payload method into the JIT loop, which is needed to get clean assembly. -XX:CompileCommand=PrintAssembly,package.class::method() to print the assembly of the payload (can check -XX:CompileCommand=help for usage as well). And that should be all.
5. Having the ability to specify JVM arguments somehow also seems necessary, since that can affect JIT output. As well as different version of Java, perhaps from different vendors (but starting with the latest GA version is probably fine).
6. Getting output from PrintAssembly also requires the hsdis plugin to be available (putting it on the PATH is probably the easiest). There are several flavours of this plugin found in the openjdk/jdk repo under src/utils/hsdis (there's a readme with build instructions there as well).

[Zireael07]

I would actually like to request Lua non-JIT! Apart from Erlang, Lua's VM is the best known register based VM as opposed to more popular stack based VMs and therefore I am sure lots of people are interested in seeing the bytecode it runs.

[gautam1168]

Please see this discussion where I'm asking about adding a similar thing https://github.com/compiler-explorer/compiler-explorer/discussions/4700