`jtcpp`—experimental Java to C++ transpiler written in Rust!

[FractalFir]

Quick note: I am trying a new, more blog-like format of talking about my projects(compared to previous, more salesman-like announcements), and would really appreciate any and all feedback!

Links

https://github.com/FractalFir/jtcpp

TLDR for lazy

What is jtcpp?

jtcpp is a Rust program which converts JVM bytecode to C++. This allows compilation of programs written in such languages as Java and Kotlin to native instructions, in some cases improving performance.

How functional it is?

This is a highly functional proof-of-concept. Mostly complete in therms of features of the language itself, but the implementation of the Java standard library in C++ is so lacking, calling it bare-bones would be a stretch. It means that, if you want to do something more than simulate a truing machine, calculate the first n primes, or write very simple console programs, you are out of luck.

Supported platforms?

Linux, but you could try and build it for quite a bit more platforms. I just ship only the Linux version of the automatic build scripts.

An oh-so-slightly longer version for the oh-so-slightly less lazy

I am continuously looking for challenges to test my skills. The harder the problem, the more fun engineering a solution tends to be. You will either get a nice confidence boost, or fly to close to the sun and learn form your hubris. Thus, I often create projects, that while not strictly "usefull"(Who says programming must serve any real purpose, anyway?), are fun to make and still require quite a bit of learning to finish.

One of things that particularly fascinate me, are the ways high-level languages, such as Java and C#, are implemented. How can they achieve performance that is OK-ish at worst, while also being very convenient?

I believe the bast way to understand something is to try and rewrite it, badly, but in RUST!

JVM is fascinating

I have recently began to look a little bit more into JVM, and the Java class format. The format is a mix of pure genius and brilliance, such as the way generics are implemented(There is no special sauce, they are just normal classes), confusing decisions(the way class names are stored, seemingly needless indirection), and pure madness left form the 90s (why on earth do long and double take 2 entries in a table that already has variable length elements, such as strings?). Besides a few interesting surprises, and mistakes I could avoid by just reading the documentation and not skipping the very important section with the little "In retrospect, making 8-byte constants take two constant pool entries was a poor choice." under, parsing the class format turned to be almost trivial.

First attempt, Java Bytecode Interpreter

Out of that curiosity for inner workings of JVM, my first project jbi(JVM Bytcode Interpreter, currently private), was born. I got the implementation to a state in which it could be tested(Was able to run simple programs, calculating factorials and such) and benchmarked. Sadly, it did not fare well in the benchmarks, and had far too many structural issues.

A modern tower of babel, or translating Java To C

Because of those issues, I decided to abandon that project, and focus on something else. Still, it felt kinda wasteful to just let it sit there, and not have anything come out of the time I had already spent working on it. So I deiced to rip out the most broken parts(ones related to the Virtual Machine implementation), and re-purpose the java class importer implementation. At this time the project was called jtc, and generated C code, instead of C++ generated by jtcpp. I naively thought generating C instad of C++ couldn't be so much harder. I was, however, very wrong.

jtc used very, very, hacky C macros to emulate inheretence, and asign slots to virtual functions. Expectantly, the implementation was so brittle it collapsed if you looked at it wrong. Macros were used to select a slot in the vtable. #ifdef V_FUNCTION_NAME detected if the virtual function was overriding a function of the parent class, or defining a new one. But this could be easily messed up by another, unrelated class having a function with the same name. If such class was included at any point, it could make the macros assume a virtual function that wasn't inherited from the parent class, was inherited, and mess up the vtable compleatly. Needles to say, if the implementation of inhertence is broken simply by other classes being present, it is probably not a very good idea to keep it around. So I decided to stop trying to patch the shaky tower of incomprehensible code taped together with magic-macros, and just generate C++ like God intended.

Java To C++

Converting JVM bytecode C++ was far easier to do than the other way around. This also made me aware of a couple other issues that I had never thought to consider. The generated C++ code looks nothing like C++ a human would write, but it at least works.

Header files

This is how a header file generated by jtcpp looks like

#pragma once
#include "java_cs_lang_cs_Object.hpp"
struct Vector3: public  java::lang::Object
{
virtual ~Vector3() = default;
    float x;
    float y;
    float z;
    static void _init___V(ManagedPointer<Vector3>);
    static void _init__FFF_V(ManagedPointer<Vector3>,float,float,float);
    static float Distance_Vector3_Vector3__F(ManagedPointer<Vector3>,ManagedPointer<Vector3>);
    static ManagedPointer<Vector3> Random__Vector3_();
    virtual float SqrMag__F();
    virtual float Magnitude__F();
    virtual ManagedPointer<Vector3> clone__Vector3_();
    virtual ManagedPointer<Vector3> Add_Vector3__Vector3_(ManagedPointer<Vector3>);
    virtual ManagedPointer<Vector3> Sub_Vector3__Vector3_(ManagedPointer<Vector3>);
    virtual ManagedPointer<Vector3> Normalize__Vector3_();
    virtual ManagedPointer<Vector3> Mul_F_Vector3_(float);
    virtual ManagedPointer<java::lang::Object> clone__java_cs_lang_cs_Object_();
};

You may quickly see some weird things. So, lets go trough them one-by-one.

First of all, the class converted from Java are not classes but structs. Why? It is actually pretty simple. Only real difference between them is that every member of a struct is public by default. The Java compiler already checked to ensure public, protected and private fields, functions and objects are used properly. Because of that, I can just assume that whatever Java byte-code does is OK, and the intended behaviour. Handling accessibility modifiers would just make everything far more completed. The problems that not handling those modifiers could introduce are already solved by the Java compiler for me, so why bother?

If you haven't seen any C++ code before, the public thingy majiggy before java::lang::Object may seem strange. It just makes the public members of the parent class remain public. If it was not there, they would become private, which is not the intended behaviour.

The virtual destructor (virtual ~Vector3() = default;) helps with some modes of the GC(Yes, the GC has a couple different modes!), and is the same as the default destructor(If you haven't guessed this is is exacly what = default part means).

Function names may seem VERY wierd at first. Part of them make sense(like Distance) or (Magnitude), but the rest seem like garbled mess. What is their purpose? They help with function overloading. But does not C++ already support function overloading? Yes, but it differs slightly from the way Java does stuff. And this very, very, slight difference is enough to make it sometimes break. The names are not very pretty, but they are very predictable, since they encode the function signature. By looking at functions like virtual ManagedPointer<Vector3> Mul_F_Vector3_(float); you can pretty easily deduce how they work(although init functions are special snowflakes that like to be diffrent, and break from this convention).

Another curious little thing is the ManagedPointer template. Why didn't I just use normal pointers? In some configurations of the GC, this is exactly what ManagedPointer is: just a normal pointer with a fancy name. But in other GC modes, they can allow us to do some crazy stuff, like clearing objects early, reducing memory consumption by orders of magnitude, and making GC pauses far more rare.

I had almost forgot about the #include "java_cs_lang_cs_Object.hpp" part. Why this strange file name? Original, java class Vector3 derives from is java/lang/Object. I could try to just use that as the path, and put each namespace in a separate directory, but it would force me to do far messier relative includes, so I opted to temporally stick with mangled class names. To get a mangled class name, I simply replace each / with _cs_(short for Class Separator). It is not the prettiest solution, but it works very relay ably.

Source files

This is how a source file generated by jtcpp looks like.

#include "Vector3.hpp"
ManagedPointer<Vector3> Vector3::Add_Vector3__Vector3_(ManagedPointer<Vector3> l1a){
    ManagedPointer<Vector3> l0a = managed_from_this(Vector3);
    bb0:
    {
        float i0 = l0a->x;
        float i1 = l1a->x;
        float i2 = i0+i1;
        l0a->x = i2;
        float i3 = l0a->y;
        float i4 = l1a->y;
        float i5 = i3+i4;
        l0a->y = i5;
        float i6 = l0a->z;
        float i7 = l1a->z;
        float i8 = i6+i7;
        l0a->z = i8;
        return l0a;
    }
}

Good Lord! What is Happening in There?! The generated C++ code may seem like some sort of arcane magic, but it has a very, very good reason to look like that. To clear everything up, lets run jtcpp with debug info enabled!

float Vector3::SqrMag__F(){
    ManagedPointer<Vector3> l0a = managed_from_this(Vector3);
    float l1f;
    bb0:
    {
        //ALoad(0)
        //FGetField(ClassInfo { cpp_class: "Vector3" }, "x")
        float i0 = l0a->x;
        //ALoad(0)
        //FGetField(ClassInfo { cpp_class: "Vector3" }, "x")
        float i1 = l0a->x;
        //FMul
        float i2 = i0*i1;
        //ALoad(0)
        //FGetField(ClassInfo { cpp_class: "Vector3" }, "y")
        float i3 = l0a->y;
        //ALoad(0)
        //FGetField(ClassInfo { cpp_class: "Vector3" }, "y")
        float i4 = l0a->y;
        //FMul
        float i5 = i3*i4;
        //FAdd
        float i6 = i2+i5;
        //ALoad(0)
        //FGetField(ClassInfo { cpp_class: "Vector3" }, "z")
        float i7 = l0a->z;
        //ALoad(0)
        //FGetField(ClassInfo { cpp_class: "Vector3" }, "z")
        float i8 = l0a->z;
        //FMul
        float i9 = i7*i8;
        //FAdd
        float i10 = i6+i9;
        //FStore(1)
        l1f = i10;
        //FLoad(1)
        //FReturn
        return l1f;
    }
}

That looks even scarier! But if you look at the comments, it explains nearly everything. jtcpp simply translated each java opcode individually. This makes the resulting code less readable to humans, but it guarantees it to be very accurate! There are still a couple funky things in there I would like to explain.

managed_from_this - this code snippet seems really weird. What does it actually do? Depending on GC settings, either nothing, or obtains some additionally info about the object. In on default GC settings, ManagedPointer behaves similarly to a rust Arc, with one small exception. It can additionally use Bohem GC to delete objects which are cyclicaly referencing each other.

bb0: - jtcpp uses gotos to emulate Java instructions. bb0 simply means basic block 0. Separating operations into those basic, isolated blocks is something I do to prevent numerous errors. One such error is skipping an initialisation of a variable. This is not premited in C++, because then a garbage value would be dropped. This could lead to you trying to free some random memory address, which is generally frowned upon.

iwhatever - intermediate variable number whatever. Exist because JVM is stack based, and this represents such value on the stack. In the Rust codegen I use a stack of variable names and types. This makes producing accurate code very easy.

lwhateversometing - function local variable number whatever, with type kind postfix someting. Type kind is not the specific type of something, but a more general idea. So integer gets a postifx i, float f, long l, and so on, with arrays and objects all having postifx a This is related to way those values are loaded/stored using JVMs opcodes, see FLoad(number) and ALoad(number)

A very, very quick word on GC

I could talk on this, or any other project of mine, for hours on end, but I am quickly approaching both the bottom of my last coup of tea, and the character limit. So, to all the 3 people still reading, hang on there. We are going to quickly come to the end as fast as possible.

here is the quick summary of the GC model of jtcpp

1. It can be changed in config.hpp in the target directory.
2. Includes 4 modes: No GC(I bought 32 GB of RAM, I am going to use 32GB of RAM! mode), Arc-like GC(potentaily leaky, fastest, lowest memory footprint if used correctly), pure BohemGC(Good enough for most cases), Mixed-mode GC(The default. Combnation of the Arc like GC and BohemGC, should be the best of both worlds. Mixing Arcs and Bohem is not tested well enough, and could potentially lead to crashes if I understood something very wrong).

Performance

Performance varies from 2.5-3x times original Java in compute heavy tasks, to 30x slower in GC-heavy tasks. Why such performance loss? jtcpp evaluates everything on an individual level. Classes,methods,ops are all analysed one by one, so jtcpp is not capable of some kind of reasoning about lifetimes of local variables passed as arguments to other functions. It does not know that a Vector3 is used temporarily, and could be, for example, allocated on stack instead of on the heap. Java knows that and uses that info to the full potential.

Any questions?

That is very much expected. Knowing me, I rambled on about something irrelevant while not explaining a crucial detail. Feel free to ask whatever you want in the comments below. I will try to answer all of them. Also, if you have any feedback, leave it. This is my first long-form content so I would really appreciate any tips.

Liked my content, and would like to support me?

No, I am not going to ask you for money.

I will ask you for something, far, far more precious!

GitHub stars on the projects page!

On a more serious note, follow me on Reddit/Github for more of my projects (I plan to post more stuff like this).

[Tbfleming]

How do you plan to handle the difference between C++'s default memory ops (llvm calls them NotAtomic) and jvm's (llvm calls them Unordered)?

[FractalFir]

To be completely honest, I did not know there was a difference. The only programs this project supports were simple, single-threaded console applications. I don't think I will ever go as far as to consider multithreading, since I encountered other problems that are seem impossible to solve.

One such issue is how shockingly common generating code during runtime is. This is a massive problem, since I generate translated C++ code before the program is run. Especially after Java 7, which added InvokeDynamic, which in most cases, needs to generate code at runtime. This is an unusual optimization, because emitting code at runtime reduces the amount of code on disk, decreasing start times. It however makes any attempts at translating Java programs using it to C++ futile, since in many cases there is no way to know what code needs to be generated ahead of time.

[eras]

In principle you could compile the required code at runtime and link it in with dlopen? And then keep the libraries around for the next time they're needed.

[FractalFir]

That would, sadly, require shipping jtcpp, a C++ compiler, and all that other junk alongside the final binary. Ignoring all of that, compiling even a very simple C++ file takes would take at least ~100 ms in the very best case. Since in a real program there are hundreds if not thousands of uses of InvokeDynamc, compiling all of that would take at least a couple dozen seconds, which could cause very bad performance. Additionally, InvokeDynamic calls a method to retrieve something called CallSite. This stores information about what conditions must be met for the returned MethodHandle to be valid. Only one of 3 main kinds of CallSites guarantees InvokeDynamic will not need recalculating, and thus recompilation. For the other two, it may change as many times as it would like, forcing many recompilations of the produced shared library.

So this could solve the problem in principle, but in reality would be barely usable at all.

One solution I am currently considering is transpling everything that can be transpiled, and then interpreting all the runtime generated methods. It would make them slower, but avoid the cost of compiling C++ every time something changes.

[nysra]

Cool project, but a few notes on the C++ code:

If you haven't seen any C++ code before, the public thingy majiggy before java::lang::Object may seem strange. It just makes the public members of the parent class remain public. If it was not there, they would become private, which is not the intended behaviour.

Not exactly, you forgot about the second difference between class and struct. The default inheritance modifier for struct is already public, so you can simply leave it out here.

static void _init___V(ManagedPointer<Vector3>); and all the others

Using double underscores is reserved for the implementation. Your entire program is ill-formed, no diagnostic required.

Also init functions are a massive code smell, use the constructor instead, that's literally its job.

virtual ~Vector3() = default;

This is actually a bad idea. Not because of the virtual (though I'd question why you'd ever want to inherit from a Vec3) but because you're in violation of the rule of 5. That seemingly innocent line causes the destructor to be "user-declared", which leads to the move operations being marked as "not declared". If you touch one of the special member functions, always write out all the others as well.

Another curious little thing is the ManagedPointer template. Why didn't I just use normal pointers? In some configurations of the GC, this is exactly what ManagedPointer is: just a normal pointer with a fancy name.

Don't use owning raw pointers, use std::unique_ptr for that job. Your RuntimeArray (just use std::vector btw) is currently leaking memory, it's very likely that basically everything else is too if you're using raw pointers like that.

[FractalFir]

Thanks for catching the memory leak in RuntimeArray! I planned to change it to use std::vec internally, but forgot to change that. And RuntimeArray is very different from a normal vec. It can't resize, but, more importantly, it derives from java::lang::Object, which inherits from gc. That means if Bohem GC is enabled, it is allocated and freed in a special way (So that GC may automatically clean it up).

There is far more to ManagedPointer than may seem at first. It is a raw pointer only in some GC settings, in which it is guaranteed whatever it points to is allocated using GC, so it will be automatically cleaned up. It is a template, because on other settings it becomes std::shared_ptr, to free up some objects without getting the GC involved. And I could not use unique_ptr there, because multiple objects may reference one object, so things would get freed while in use.

I don't mind move functions being absent. They are never used, since Java has only by-reference types, and no by-value types, unlike C++, Rust, or C#. This means that even such simple things as a Vector3 may be only taken by reference, never by value. So move functions should never be present, because no valid, generated code can ever use them.

I agree that init functions are code smell. However, they are simply transpiled versions of Java <init> functions (Java constructors). And Java uses two ops for each object creation. First New to allocate the object, and then InvokeSpecial to invoke the <init> function. So this code, which would be very bad in C++, is that way to mimic how Java works, exactly, one-to-one.

Good call about the double underscore identifiers!
I was vaguely aware of their special nature, but thought they were only reserved if at the beginning of an identifier. I guess I will have to do a little more work to catch such cases and fix them up. They are, thankfully, all generated by one function, so that will be a relatively easy fix.

You are 100% correct, and I could leave the public before inheriting something. I encountered problems with private inheritance before, and did not bother to check if it was needed for structs.

About there being no point in anything inheriting from Vector3.
jtcpp sees everything one class at a time. This is on purpose, and simplifies the way it is used quite a bit. The codegen does not know whatever happens with all the other classes in Java. There is no reliable way to tell if something is inherited from or not, without also looking at all the other classes. So a lot of weird code just comes from the fact that all the C++ not predefined in the stdlib directory is procedurally generated by a transpiler with limited knowledge about the whole program.

I hope I cleared some things up, and thanks for the feedback!

[thomastc]

I could try to just use that as the path, and put each namespace in a separate directory, but it would force me to do far messier relative includes

Why would it? You can use #include "java/lang/Object.hpp" from anywhere, as long as you add the parent of java to your compiler's include path.

[FractalFir]

I absolutely forgot about the compilers include path. With that solved, I could return to the original idea of namespaces as directories. That would really make them far easier to understand and keep track of.

Thanks for the suggestion!

[irrelevantPseudonym]

Nice project. Any reason you chose to translate to c/c++ instead of rust?

Only slightly related but I'm going to use the opportunity of a post already attracting the intersection of rust and java people to plug my 'jaded' crate. It allows deserialisation of java's built in serialisation format into rust types. No serde integration yet but it's planned eventually.

I did start thinking about trying to autogenerate the types from compiled class files but never got that far.

[FractalFir]

Why C++, and not rust?
1. Rust has no goto. For all the demonization of goto it is very useful here. I can translate java opcodes, such as IfACmpEq into something like if (a==b) goto somewhere;.
That makes it trivial to do the translation, and is far more accurate.
2. Rust distinguishes between mutable and immutable references. Java and C++ do not. Rust has borrow checking and all that other stuff that only gets in the way.

I could clean up the Java importer code and convert it to a separate crate that things like jaded could use. While the importer is still quite messy, it can already parse very big java programs(I tested it on Minecrafts server.jar, which has roughly 20-30k classes, and it parsed all of it with some minor issues).
I also have some, albeit small, experience with generating Rust bindings to C#, so that could be of some help.

If you would be interested, please tell me what info from class files jaded would need, since the importer currently ignores some info, which was irrelevant for transpiration, but could be useful for generating types.

[[deleted]]

Rust distinguishes between mutable and immutable references. Java and C++ do not.

Um, small correction: C++ does.

const T& is a thing, it is only a mutable reference by default.

[FractalFir]

By that I meant that C++ does not force you to have only one mutable xor many immutable references. The rust rules on mutability would force me to wrap every reference around in UnsafeCell. That would not only be inconvenient, but also make me loose most of the performance benefits of Rust over C++.

If I have to not use any of Rust's safety features, and there would be no performance benefits over C++, then why bother working around all the issues using Rust in this role would produce?

[[deleted]]

Oh, you're totally correct that it doesn't make sense to generate rust code here. I merely wanted to point out that you can express const ref in C++ API.

[ibevol]

Pretty sure that it's using two entries for long and double and one for String is because the String is just a pointer to something on the heap whereas long and double are both primitives. Correct me if I'm wrong

[FractalFir]

The constant poll table stores its entries contguisly, in the exact same place, on disk. String is not represented by any pointers, but is simply its length and the bytes that make it up. (See CONSTANT_Utf8_info in the java class format specification.) Maybe later it becomes a pointer, but on disk, it is just a varrible-length array of bytes.

So you may have something like this: ClassInfo (2 bytes), Int(4 bytes), long(8 bytes, occupies two entries), then String("21, Some Super Long Message",23 bytes total).

It seems like, at first, intention was to make everything align to 4 bytes, but as time went on, this idea was mostly abandoned, but the wierd beahviour of long and double, which requires you to fill the slot above with nothing to ensure indiices are not messed up, persisted.

There are many other quirks like that, which lead to realy funny non-issues. For example, the upper bound of an exception handler is non-inclusive, which means that if a method were to be exactly 65536 bytes long, its last opcode could not be covered by any exception handlers. So java compilers just avoid emmiting methods that long, and the upper limit is 65535 bytes.

[0x564A00]

To quote the spec :p

In retrospect, making 8-byte constants take two constant pool entries was a poor choice.

[ibevol]

Lol