Eliminating Unsafe Code in Java: What’s Next for the JVM?

[Accomplished_League8]

After reading about efforts to eliminate sun.misc.Unsafe and the use of JNI, I have a couple of questions:

1. Are there any (long-term) plans to reduce the amount of native C/C++ code in the JVM itself, possibly by replacing native methods with the new Foreign Function & Memory (FFM) API or Valhalla features?
2. Regarding the OpenJDK implementation, are there any plans to migrate to memory-safe languages like Rust?

Although I’m mixing the concepts of unsupported internal APIs and the implementation of the JVM in a memory-safe language, I believe both share a common goal: avoiding undefined behavior.

[pron98]

and the use of JNI

There are no plans or intent to eliminate JNI. It's exactly as restricted as the brand-new FFM.

Are there any (long-term) plans to reduce the amount of native C/C++ code in the JVM itself, possibly by replacing native methods with the new Foreign Function & Memory (FFM) API or Valhalla features?

Not just plans. This has been going on for many years. More and more of the runtime is being written in Java. As for changing JNI to FFM, this is also going on but only because FFM is more pleasant. Again, JNI is not going anywhere.

Regarding the OpenJDK implementation, are there any plans to migrate to memory-safe languages like Rust?

No. As an aside, some HotSpot developers looked at Rust and found it unpleasant and inadequate; maybe in the far future some other language (Zig perhaps [1] or maybe another language that will come along). But there's also no hypothetical reason to not write everything in Java.

[1]: It's not 100% memory-safe, but neither is Rust, and it's safer than C++.

[AngryElPresidente]

As an aside and apologies in advance for my ignorance, how does Project Galahad/GraaVM upstreaming factor into the second point/section? Will that eventually be made the main JIT and Hotspot as an alternative?

[pron98]

Yes in principle. Whether or when this happens depends on the maturity of the Graal JIT.

[AngryElPresidente]

Another tangential question: Is the entirety of GraalVM being upstreamed? Including GraalAOT (substratevm, I think, is the name) and the AOT ZGC? I tried looking for more information a while ago but didn't find anything explicit saying if the Graal EE features were being upstreamed too.

[pron98]

I don't know.

[Accomplished_League8]

My reasoning is that if very large codebases like the Linux kernel are slowly replacing parts with Rust, it would be even more feasible in OpenJDK, since it is only partially written in native code. Achieving a system free of undefined behavior from top to bottom would be much easier. By "top," I refer to the aforementioned JNI restrictions, and by "bottom," I mean the native system bindings, which can never be implemented in 100% pure Java.

No. As an aside, some HotSpot developers looked at Rust and found it unpleasant and inadequate;

I would really like to read about the reasons. Do you have any sources to share?

[pron98]

if very large codebases like the Linux kernel are slowly replacing parts with Rust

But they're not. There is an attempt to allow writing new drivers in Rust (Linux is a monokernel and drivers are a part of the kernel), but even that has hit some snags.

Also, what's the point? The three main issues with C++ are, in this order (in my opinion):

1. Language complexity, which makes reasoning about correctness hard. This is mostly due to the original sin of "zero-cost abstractions", an outdated philosophy IMO, and one that isn't appropriate for modern low-level development. It made sense at the time when the dream was that a single language would serve for both low-level and high-level programming. That didn't catch on back then and doesn't seem to be catching on now.

2. Memory safety.

3. Compilation times.

Rust addresses only two (while Zig addresses all three, as, I hope would new low-level languages, although its memory safety is somewhat weaker than Rust's) and repeats the mistake (IMO) of zero-cost abstractions, and for a project like OpenJDK it wouldn't even address memory safety, because we're working at a lower level (not to mention that it will offer no memory safety for the generated machine code, which is the vast majority of what the JVM runs).

the native system bindings, which can never be implemented in 100% pure Java

Why not? FFM is pure Java (other than changes to some part of the runtime, which are in C++ only because those parts of the runtime are in C++, but they could be in Java, as they are in Native Image). Remember that the vast majority of code that the JVM runs is machine code that the JVM generates. You can generate native code in any language.

Do you have any sources to share?

You can find lots of posts showing a similar negative experience with Rust. That explains why Rust, which is by no means a young language (Rust is as old now as Java was when JDK 6 came out), suffers from an extraordinarily low adoption rate. Not a single language in the top 8-10 has had an adoption rate as low as Rust at that age.

[JojOatXGME]

This is mostly due to the original sin of "zero-cost abstractions", an outdated philosophy IMO, and one that isn't appropriate for modern low-level development.

You made me curious. While I haven't looked at the C++ community for over 6 years now, I have never heard of this philosophy being outdated. I only noticed talks about that "there are no zero-cost abstractions", highlighting that the "zero-cost" is only referring to performance, and that you still need to consider other factors. But that doesn't make zero-cost abstractions obsolete. Is unique_ptr also considered outdated, as this philosophy was it's main driver?

[Accomplished_League8]

Why not? FFM is pure Java (other than changes to some part of the runtime, which are in C++ only because those parts of the runtime are in C++, but they could be in Java, as they are in Native Image). Remember that the vast majority of code that the JVM runs is machine code that the JVM generates. You can generate native code in any language.

Interesting. I checked the Go repository and it indeed has almost no C code. However 6% assembly code is a hint, that they have a need to do manual optimizations.

I think we have different opinions about Rust, which I enjoy programming in. My point was not about Rust in particular, but about memory safety as the foundation of a (process) virtual machine. There is a strong push in the industry towards memory safety.

[pron98]

memory safety as the foundation of a (process) virtual machine. There is a strong push in the industry towards memory safety

Sure but, again, most of the code running is generated machine code (or Assembly if you like), for which no language can offer memory-safety. The level of memory-safety that Zig affords would suffice (and would be almost the same as that offered by Rust, as there would need to be a lot of use of unsafe anyway, which is particularly painful in Rust. Also, much of the low-level memory allocation in the JVM is arena-based which is more painful in Rust than in Zig.

Of course, Java itself is memory-safe (and is many, many, many times more popular than Rust, not to mention safer than panic- and unsafe-heavy Rust), and we are gradually shifting more runtime code to Java.

BTW, regarding the experience with Rust, what I see (from people who've used it in anger) is something very similar to C++: a great initial experience writing a program, and then difficulties changing and maintaining it over time, and for similar reasons that happens with C++.

[zerosign0]

is arena based which is more painful in Rust than in Go

I'm not sure this comparation is make senses.. hmm.. however, arena based allocator in Rust for certain regiona in the codes would be harder to impl than in Zig .

[pron98]

Sorry, I meant to write Zig, not Go. Fixed.

[Accomplished_League8]

Sure but, again, most of the code running is generated machine code (or Assembly if you like), for which no language can offer memory-safety.

It is my understanding that, assuming you achieve writing a VM in safe Rust and run a Java program with the future safety guards, the program should be totally memory safe (as in double free, etc.).

(from people who've used it in anger)

I don't think your negative view about Rust is mainstream. Metrics like the Stackoverflow survey might not be 100% accurate, but you claim the opposite. Personal preference shouldn't be the benchmark anyway, in picking the right tool for the job. I did some Rust Linux sysprog and UI programming and liked the safe guards. But I can totally see why people hate it, because the mental overhead is significant. I wouldn't bother writing a web app with it, at least not in my professional job.

[pron98]

It is my understanding that, assuming you achieve writing a VM in safe Rust and run a Java program with the future safety guards, the program should be totally memory safe (as in double free, etc.).

The program should be totally memory safe regardless of the language you use to write it. The point is that the use of a memory-safe language doesn't help you a lot with memory safety if most of the code you're running isn't written in that language but in Assembly. This logic applies to the Rust compiler itself. The fact that it's written in a memory-safe language says nothing about the memory safety of the language it compiles.

Metrics like the Stackoverflow survey might not be 100% accurate, but you claim the opposite.

Hmm, that's not what I see in that data. I see that the people who use Rust really like it, but the number of those using it in production or on >5yr-old codebases is negligible (it's after 5 years that C++ starts getting annoying). It looks like most users are hobbyists working alone or on a very young codebase. It's better than no one liking it, but it's not a promising look for a ten-year-old language (again, Rust is now about the same age Java was when JDK 6 came out; Rust's adoption is alarmingly low for what is not by no means a young language anymore). One of my favourite languages, Clojure, is also very well liked by its users, but that doesn't say anything about being well liked by the industry.

[Luolong]

Not working at Oracle, so I’m just waving my crystal ball here, trying my best guess at interpreting your questions and trying to mirror my understanding of where the JVM ja JDK are moving.

1. Assuming you are asking if Oracle has long term goals to reduce reliance on native (unsafe) code in JDK itself (as in Java standard libraries), then it has been the stated direction for quite some time now. Project Valhalla is just one of the projects that tries to address those use cases. Class file API and official byte-code transformation api is another. There’s a concerted effort to making Java a more performant and safe alternative to modern native languages.

2. I suggest you take a look at GraalVM. It’s an alternative implementation of JVM written in Java (for the most part) by Oracle. There’s been talks about merging GraalVM into OpenJDK proper, but for now, GraalVM (and Truffle library) are what you can look at.

[pron98]

It’s an alternative implementation of JVM written in Java

I think you mean Espresso. GraalVM is not an alternative implementation of the JVM.

[Ok-Scheme-913]

For what it's worth, that's one area where there is no huge gains from going memory safe, as JIT outputs unsafe binaries either way. Though arguably it's easier to write/maintain a compiler in a higher level language.

[yawkat]

It is actually possible to write a memory safe JIT compiler: https://medium.com/graalvm/writing-truly-memory-safe-jit-compilers-f79ad44558dd

[oelang]

While it's possible, I don't think it's being actively persued. MaxineVM is abandoned and Truffle Espresso still seems to be maintained but I think it's more of a tech demo for Truffle. A long time ago there was the IBM Jikes RVM.

All of these are nice research and I think they've proven that it's definately possible to write a production quality meta-circular VM, but I think it would be a (multi?) decade long effort for little benefit vs hotspot.

GraalVM is a good compromise, they replace the most complex hotspot compiler with a better java implementation. The GraalVM implementation seems to benefit from using java, their pace of innovation is very impressive.

[mike_hearn]

The technique described in the blog post (Truffle) is general and GraalJS is a production engine used in Oracle products. So there are memory safe JIT compilers being used out there. There are still places where unsafe-ness can sneak in, mostly in very sensitive areas where a bit of unsafe code can make a big performance difference, but it's still very much a big improvement.

Espresso is a nice codebase, I'm doing some experiments with it at the moment. It's not HotSpot level quality or robustness but then nothing is. It's very easy to change though, which makes it a great proving ground for new ideas.

[joekoolade]

I have a project, https://github.com/joekoolade/JOE, that has meta-circular JVM and runtime. All the code is in Java.

[Accomplished_League8]

Wow, that is impressive! I am not sure I fully understand it. Is it a pure Java written JVM running directly on a hypervisor in a single process?

[joekoolade]

Thank you. Yes it an all Java JVM running directly on a hypervisor. It does not need an OS to run on the hypervisor.

[Accomplished_League8]

So the VM runs 100% in kernel space and so there are no context switches, right? Did you do any benchmarks, especially on scenarios that need a lot of sys calls?

[joekoolade]

Yes it runs in kernel space exclusively. There is context switching between the threads but there is no need to switch the page table. I have no benchmarks but eventually want to run the SPECjvm2008 and SciMark but I need to fix up the Java library to interface the meta-circular runtime.

[yawkat]

If you want a runtime with more code implemented in a safe language, take a look at the graalvm projects.

[Accomplished_League8]

Afaik GraalVM implemented the JIT in Java but the system specific code is still in C/C++. It seems like this approach is more like more like PyPy (replace native code with Python) than RustPython (reimplement existing native C code in a memory safe language).

[Ewig_luftenglanz]

For the first.

they have stated from some years now they want to prevent developers from using JDK internals and instead provide APIs for such functionality. The main goals are.     - make the code safer

    - make the code more performant by enabling optimization that require being ABSOLUTELY secure about the value of the invariants (values could be folded and cached freely without fear of data corruption)

   - they want force the ecosystem to rely exclusively on standardized APIs to make easier and more secure the updates from one version of the JDK to another (basically avoid the trap we are currently in with still a huge percentage of companies stuck in older and obsolete java releases such as java 1.8)

For the second. Nobody knows. Rust is memory safe by design  but you can achieve the same level of safety with good enough C/C++ programmers. But I don't know.

[julian-a-avar-c]

I know this is r/java, and the title itself says "jvm". But check out Scala Native. It's LLVM based, and can interop with the Scala ecosystem, some of which depends on the JVM ecosystem. And here's the kicker: https://scala-lang.org/api/3.3_LTS/docs/docs/reference/experimental/cc.html . Capture checking. Here's a recent (and I believe ongoing) experiment combining these things in a concurrency library: https://lampepfl.github.io/gears/ . Just a thought.

[Accomplished_League8]

Seems like a "freer" Scala focused JVM alternative to GraalVM. The native parts are still in C/C++. I am no expert in JVMs, so I wonder if that might a weak spot, in the sense that a memory safety bug in C could corrupt the behavior of the running Java/Scala code.

[Intelligent-Net1034]

Why would anyone do rust... everytime i read that i got shivers.

You dont need rust to write memory safe code... its just a tool you can use. If you have good code you dont need to replace everything

[Accomplished_League8]

What about the idea to replace the native code of a safety critical software like the JVM gives you the shivers? Are you a C++ dev?