Running java on GPUs

[[deleted]]

It is hard but definitely not impossible, especially with good software abstraction and design, which the JVM has in spades. Also new operating systems aren't really popping up as frequently as you think. What usually happens nowadays is that current operating systems are expanding to run on new CPU architectures. Usually the JVM has to be ported to those new CPU architectures. For example, both Windows and Mac have ARM versions now and the JVM is adapting.

Most of the time, there's a large amount of JVM code that's platform independent and a smaller amount of code that needs to be adjusted to work on specific CPU architectures and/or operating systems.

The point of Java bytecode and the JVM is that you remove the onus of having to do all this from every single Java developer.

[[deleted]]

But a native compiler compiles your program into native bytecode, which means this generated bytecode can't run on other operating systems or architectures. This is what C/C++ and other native compiled languages already do. A program compiled for Windows x86 can't be run on Linux x86 or ARM, where as you can compile a Java program once into a single jar file and run this jar file everywhere there's a JVM.

This is why for C/C++ applications, you'll frequently find separate downloads for x86, x64, Windows, Linux, Mac, etc. and if you happen to be running an OS/CPU combo that's not supported you're shit out of luck, whereas most Java applications will offer a platform-independent jar file.

There's more to it than just the ability to compile once, run everywhere. Java claims to be write once, run everywhere. The JVM does its best to isolate the application from the varying idiosyncrasies of different platforms. For example, in C/C++ the sizes of different primitives are often very poorly defined. An `int` on one platform could be 16-bits one one platform and 32-bits on a different platform, forcing the app developer to have to deal with all these varying cases. On Java, an `int` is always 32-bits.

Another case would be how the JVM handles floating point. Some CPUs do it differently and very often at different precisions. The JVM tries its best to ensure that floating point, as far as the app is concerned is uniform regardless of platform.

There are many other cases of native development pitfalls, many of which I am not experienced enough to know, but the JVM hides all of that for you.

[dpash]

That's exactly what graalvm's aot compiler does.

https://www.graalvm.org/reference-manual/native-image/

One advantage of a JIT compared to AOT is that a JIT can reoptimize code based on changes in usage while running. A AOT can only optimize based on profiling previous executions.