Experimenting with MIR as Java JIT

[glegris]

Hi,

I have tried to use MIR as Java JIT. I started with a lazy approach using the C frontend: Java bytecode -> C -> c2mir
As expected, I first tried a simple HelloWorld. Note that a simple HelloWorld requires a lot of classes in Java, so this is not such a trivial test.

Results on a Core i5 5300U

Java to C conversion time is ~2s. A big C file is generated instead of one C file per class to avoid parsing the same headers again.
Measurements below are times to build executable code from the C code:

• MIR: 13s.
• GCC (-O0): 20s
• TCC: 1,3s

It's the same bulk compilation speed ratio than in your last article.

To speedup things, a simple solution could be to precompile standard library classes but it doesn't solve the issue for big user codes.
So currently it seems the only solution to get acceptable startup time is probably to emit MIR binary code.

[rofl0r]

do you also have some comparisons for execution speed?
and may i ask, how do you convert java into C ?

[glegris]

I convert Java to C with a transpiler (not yet on github) which parses bytecode (using the ASM library) and generates C code. It can transpile itself. So the Java transpiler can be converted to C. If you add a JIT with a C frontend like MIR, you obtain a kind of Java JIT.

Execution time

MIR

time ./c2m helloworld.bmir -el
Hello !!
real 0m2,264s
user 0m1,961s
sys 0m0,302s

Executable compiled with gcc -O0

time ./helloworld-gcc
Hello !!
real 0m0,006s
user 0m0,004s
sys 0m0,001s

Executable compiled with tcc

time ./helloworld-tcc
Hello !!
real 0m0,009s
user 0m0,003s
sys 0m0,004s

OpenJDK 11

time java -cp classes HelloWorld
Hello !!
real 0m0,184s
user 0m0,170s
sys 0m0,067s

[vnmakarov]

Execution time

MIR

time ./c2m helloworld.bmir -el
Hello !!
real 0m2,264s
user 0m1,961s
sys 0m0,302s

Practically all of this time were spent in machine code generator of many MIR functions. As I understand 13s was spent for C-to-binary MIR and 2sec for reading MIR and code generation and optimizations.

I worked on fast machine code generation (-O0) but I did not finish this job yet. Using -O0 (instead of default -O2) can improve the time.

Java results are even more interesting. The code probably was executed in the interpreter.

I am really interesting in this test. Could you send me helloworld.bmir file or even better the original C file can be compiled to MIR.

People already asked me can c2m generate an executable. It is possible and it is not a big work if we use a system assembler. The bigger work would be generation of PIC code as currently MIR-generator can generate only non-PIC code.

Thank you for trying MIR and sending these results.

[vnmakarov]

Thank you for sharing this.

It should be a pretty big file if tcc takes > 1sec to generate the code. tcc speed is usually 0.5-1M lines per sec.

As I understand you used GCC with -O0. Please, correct me if I am wrong.

I experimented with small C files (w/o headers) and I found that c2m compilation time is pretty close to tcc one. It means that compilation time for c2m and tcc on these files is bound mostly to time spent by different initialization code (a start up time) in the compilers.

GCC startup time is about 10 times more than c2m and tcc one.

I think that library files should be compiled once, not every time (desirably even in VM/JIT build time). For c2m it means compilation into MIR. In this case it would also decrease Java to C compilation.

Saying that I understand attractiveness to have a very fast C compiler as tcc one because it could simplify JIT implementation and its architecture.

Unfortunately, c2m was designed for compilation small files during JIT work. Speeding it up would mean completely its redesign and rewriting. To make c2m faster less passes (ideally one) and less IRs should be used, faster macro extension algorithm and parser (e.g. precedence op parser) could improve compilation speed. More compact IRs which ,for example, can be achieved when only line numbers for diagnostic are kept. I think I know how to create a C compiler whose speed is close to tcc, but again it needs complete compiler rewriting.

tcc has own drawbacks. Fast compilation speed results in absence of optimizations and slower generated code. Also tcc generates libraries and this makes JIT based on tcc useless for some systems. For example, M1 Macos requires signed dynamic libraries, it can be signed automatically by local certificate but the certificate is checked by Apple certificate servers as some certificates can be revoked and in a black list. Time for communication with Apple servers will make JIT based on tcc too slow. I am afraid that signed libraries might be a general trend in the future.

Thanks again for sharing this info. I really appreciate it.

[glegris]

Thanks for your feedback !
Yes I used gcc -O0
I will try to precompile library files.
I was not expecting fantastic performance with my very naive approach but it allows us to see what are the orders of magnitude in terms of optimization to obtain something close to a standard Java JIT.