Oracle Contributing GraalVM Community Edition Java Code to OpenJDK
graalvm.org
graalvm.org
This move is good for Graal, as it will help it compete, but there’s still a big question in my mind at least about if Graal is going to be able to compete long-term. Yes, I know Graal can also execute WASM generated binaries, so it may have a space in this environment, but will it outperform native WASM VMs? And will WASM become the de facto binary format for shipping things where JVM bytecode has been used in the past? What’s Graal’s place in the future?
Truffle is interesting because it says, no, we should not be trying to compile everything to a universal bytecode. Instead, we should JIT compile the source code directly, using the JVM as a runtime library but bypassing the bytecode layer. The language semantics can be expressed much more clearly, without needing to contort things to make them look like Java, whilst still benefiting from the JVM's core feature set.
So really I'd ask it the other way around. If it weren't for the politics of the browser world and the monolithic "Chrome is the OS" approach, would WASM be competitive? Because the Graal team already proved you can run lots of different languages at relatively insane speeds using partial evaluation and bypassing bytecode. The WASM world has proven it can run C++ and Rust at slower speeds than normal, which isn't particularly unexpected. If Chrome and Safari shipped GraalVM accessible via <script> tags, how many people would care about WASM? Remember that you can run WASM and LLVM bitcode on top of GraalVM too, it's not just about textual languages.
Arguably, if you wanted to give the web an instant free upgrade that'd make many developers rejoice, integrating Graal into Chrome would be an overnight way to do it. Python, Ruby, JVM bytecode and any other language you want at V8 like speeds, in a script tag? It's technically possible, it's just not politically possible.
Maybe you can:
"TeaVM is an ahead-of-time compiler for Java bytecode that emits JavaScript and WebAssembly that runs in a browser. Its close relative is the well-known GWT. The main difference is that TeaVM does not require source code, only compiled class files. Moreover, the source code is not required to be Java, so TeaVM successfully compiles Kotlin and Scala."
I have never had an opportunity to try out TeaVM, but it seems promising.
I should have clarified. Yes, you can probably do a native-image style "compile an app+embedded JVM to wasm" by pretending V8 is a CPU. There are programs that do that sort of thing, I think Leaning Technologies makes one. That wouldn't be of use in any existing Java project though. The only reason you'd ever want to do that is because browsers offer nothing else, even though they could and at that point why not compile to JS, at least that way your GC isn't being interpreted too. If you're not constrained by the WHATWG's decisions though it doesn't offer anything.
It looks like you mean CheerpJ: https://leaningtech.com/cheerpj/ https://github.com/leaningtech/cheerpj-meta
>> That wouldn't be of use in any existing Java project though. The only reason you'd ever want to do that is because browsers offer nothing else, even though they could and at that point why not compile to JS, at least that way your GC isn't being interpreted too. If you're not constrained by the WHATWG's decisions though it doesn't offer anything.
It is very use case and "what is the future of your Java application" dependent. Some organizations are looking into migrating off of Java due to a variety of reasons. These kind of "Java conversion" tools help to keep legacy Java applications running until the legacy Java applications can be replaced.
- run wasm interpreted on OpenJDK, similar to javascript running interpreted in nashorn, or now graalvm, you just need to add couple of graal sdk jars to your dependencies
- run wasm compiled, you need to run on GraalVM for this. This is supposed to provide around 50x speedup compared to previous point
https://www.graalvm.org/22.3/reference-manual/python/
or is that something different?
That’s a good question, and partly why I was pointing out that it’s not just benevolence for Oracle to OSS this. I don’t know if the browsers vendors could embed Graal, maybe they can, (license restrictions being some of the issues I’m sure) and then that could supplant the individual JS and WASM runtimes they support. But this wasn’t even an option until today.
> Remember that you can run WASM and LLVM bitcode on top of GraalVM too, it's not just about textual languages.
Which is exactly why I mentioned that in my original comment. Yes, Graal could be that runtime, will it? Seems like a gamble for anyone who’s not already in the JVM ecosystem to some degree.
Well, some GC'd languages support compilation to WASM, for example, you can compile go to WASM. The issue here is that for GC'd languages you have to bring your own runtime with GC in every module, so this doesn't really work.
Can someone play devil's advocate to explain how this news may actually favor this negative view of Oracle? The sentiment in this thread is praising Oracle's decision here, so I'm just curious if there's an alternative viewpoint that's skeptical or wary of this decision and Oracle's motivation to make it.
With that said, I'm not looking for reason to diminish the positives. I'm just curious. Good moves that benefit the community should absolutely be acknowledged and encouraged.
EDIT: It looks like another person commented how this may not be benevolent in the context of WebAssembly while I was slowly typing this comment up on mobile. I'd still be interested in this discussion though.
I've been at this long enough to have had my own experiences and they are indeed as bad as everyone has warned me, but it does feel like something you have to experience yourself (or at least through a trusted party like in my case) to totally believe.
The parent apologist was extremely precise in how they described Oracle. Oracle isn't in the "Be warm and fuzzy to developers" business: they're in the "Provide mission critical software to large enterprises" business. Logic for servicing the latter well makes things look screwy or sinister to people used to the former.
Which isn't to say the Oracle salespeople aren't scummy. But most salespeople are scummy. That's what happens when you incentivize closing sales, which is how almost all sales orgs are set up. So audit model + scummy salespeople = bad experiences. But to parent's point: what's a better model for their customer persona?
I'm a bit young to have ever known much about Sun, but I get the impression that they were very respected for their products and commitment to open source, and Oracle's purchase seems to have really rankled the community. Interestingly, the only Oracle products I use are all from the Sun era - MySQL, Java, Virtualbox, and ZFS.
I have no idea about this graal thing and I think it's rather niche application. I played with it but concluded that it's not ready for me yet.
The generalized dislike of Oracle you have seen really comes from a couple of different aspects, neither of which are relevant to this specific announcement:
1. License audits suck.
2. The Google lawsuit (about matters resolved long ago and which don't apply to anyone except Google, really).
A lot of ill will comes from people whose companies have been audited. The process is by all accounts very painful. However, what's rarely mentioned in such discussions is the alternatives and why Oracle does this. It's because their software is totally DRM free. It makes sense; you can't have a major airport or bank shutting down suddenly because a license key or credit card expired, can you? Oracle DB is mission critical stuff, it must be always available. That's why they use an audit model - it's "trust but verify". They make their stuff available for free download and you promise not to pirate it.
Every so often Oracle turn up and check to see if you're paying for what you're using. At this point there are usually two problems that crop up:
1. The company doesn't actually know if it's correctly paying for Oracle's stuff. It requires a lot of work to find out, maybe the right controls weren't in place and naughty developers just installed more copies because it was convenient etc. Then they discover they've unknowingly been pirating the DB.
2. And/or they discover they didn't understand the licensing model, which historically had some very sharp edges around virtualization (maybe still does).
Because the downloads are open and unrestricted by any form of DRM, it's easy to make these mistakes in a company that doesn't have good processes in place. At this point the users have a problem because it's just plain old copyright violation. Oracle prefers not to sue its own users for obvious reasons so at this point a third issue crops up - their sales guys like to cut deals. Buy more of our software and you'll have some useful stuff plus we'll forget about your non-compliance issues. Win/win, right? Not always for the people who aren't at the top of the firm of course, who may now be told to adopt some new product that they wouldn't otherwise have chosen and may not even be told why (it's embarrassing for the executives to admit they ended up in that situation!).
It's worth observing that with the cloud these problems go away. Use Oracle DB only in the cloud (or MS SQL etc) and the cloud provider will track your usage and ensure you're paying for it. In turn that means no need for audits.
It's very easy to criticize Oracle for the above outcomes. It's harder to come up with alternative approaches beyond really down in the weeds stuff like the exact ways virtualized cores are licensed, etc. The moment you have a commercial product there needs to be some way to ensure users are paying for it (because a lot simply won't if there's nothing in place to make them), but if you accept that outages cannot be caused by DRM or licensing errors, then you are almost forced to go with either the cloud or the audit+true-up approach. Many modern DB firms go hosted-only which brings its own problems (see the recent Azure leak). Plus Oracle DB predates the cloud, so ...
I guess my default (and flawed) heuristic is to assume that a big corporation has an ulterior motive with goodwill or community-focused announcements. I'll take this as a learning opportunity to not blindly adopt what I perceive as the general sentiment, to stop relying on such a heuristic, and to do my own research and evaluation. In addition to the detailed response, thank you for also indirectly kicking my butt into reevaluating how I approach the unknown both logically and emotionally.
This particular announcement isn't even meant to generate goodwill really, although I can see why it's interpreted that way. It's not like there's a new open source release coming. It's just resolving some duplication issues in the way these already open source projects are being developed by Oracle "donating" from one arm to the other :) The goodwill should instead come from the decade+ funding of this very advanced and large research project, which is teaching the world a lot about fundamental computer science (complete with large set of academic papers), and for which almost all the core cleverness is given away under liberal licenses.
Be aware that they do have a commercial offering built on top of Graal, the enterprise edition. It makes programs go faster, and has a few other useful features. But there's nothing nefarious about that of course.
A large part of Oracle's bad reputation comes from a history of entering markets, gaining a captive customer base, and then engaging in blatant rent-seeking that squeezes every last penny that they can out of their customers.
As a direct example, I'm in the healthcare space and specifically work in a Cerner shop. Our quotes from Cerner for routine integration projects have gone up literally 5-10x since Oracle acquired them. An EHR migration costs well into eight figures, so Oracle is fully aware that customers aren't easily going to be able to move away from them because things that were $15-30K (and still are with other vendors) are now running into the six figures, but it certainly doesn't leave a positive taste in the mouth.
And we knew this was coming as soon as the Oracle acquisition was announced. Because Oracle has built a reputation for doing exactly this across multiple markets over multiple decades.
Do you honestly think that all those libraries care about Pride or Black Lives Matters? Nope, they just had some calculations and as user-facing companies, marketing has a huge role on their profits. A logistic company won’t have done any such thing as they are likely not even known by the general public.
Oracle is not really an end-user facing company like Facebook or Google is, so they simply don’t care all that much about that (hence the lawnmower analogy). But.. that’s a good thing as well — you can use the lawnmower for its job, you’ll never be surprised. Graal and OpenJDK and other tech at the bottom of the tech stack are long term investments. Looking at the linux kernel, it is not developed primarily by some hacker in a basement, but by employees paid by Intel, Red Hat, Google, pretty much everyone.
Beware that this polyglot feature you've mentioned is not moving to OpenJDK.
* to run faster
* to get a better JIT compiler, better GC, sandboxing, etc
* to run using code from other JVM languages in the same process
* to get the JVM's monitoring tools
* to embed into a Java application
This may be more readable: https://github.com/oracle/graalpython/blob/master/docs/user/...
GraalVM native compilation helps Java in the data center to avoid being a cost sink and to reduce start-up latency. Oracle needs Java to sell enterprise software.
Oracle contributing to OpenJDK may be required for Amazon cooperation (since Amazon is pushing its own JDK build) and probably helps the library ecosystem work towards native compatibility.
Native support for reflection (used in many libraries) requires "reachability metadata", maps of reflective API usage, at build time. Anyone can do it, but enterprise requires authoritative sources. Until authoritative reachability metadata covers the transitive graph of library+version dependencies in enterprise software, GraalVM native AOT builds are a PITA.
- https://github.com/oracle/graalvm-reachability-metadata
- latest release: https://medium.com/graalvm/graalvm-22-3-is-here-jdk-19-build...
- graalvm "community" roadmap: https://github.com/orgs/oracle/projects/6
(As a side note: Mark Reinhold has run the JDK team since 1997: is there any comparable example of such stellar leadership for broadly-adopted software across multiple technical and organizational eras?)
But at the same time, it's also smooth sailing, and it's getting better all the time. It's still Java, for a bazillion applications it still "Just Works". It's still (IMHO) far more manageable and stable than many other platforms.
I think the combination of Oracle and the entire community around it have been marshaling it really well with little drama. Change, sure. But not Drama.
The Enterprise Edition departure was a big deal, but even that transitioned pretty well. That was no small task, and I think the vendors and framework folks have been handling that pretty well.
GraalVM is just another step forward for the entire community, and it is kind of Oracle (however motivated) to release it. In truth, I think, overall, Java has been mostly (mostly) Oracle free, despite their monster investments into the technology and community. They could have been a much less benevolent dictator.
Also, obviously Oracle didn't do this out of the kindness of their hearts, if they didn't contribute Graal into the OpenJDK the would risk to Graal never become anything other than a niche VM because most people, specially big clients don't want to change VMs and the CE version will be their new gateway drug to their Enterprise version of Graal.
Which I have no problem with.
There are some features like polyglot isolates that are currently EE, but they are just a use of native image isolates.
With Loom and GraavVM, I can have cheap treads on fast booting JVM.
For example the Go runtime and I think C# as well are written in their respective language.
I can't quite imagine how you'd bootstrap something like that.
See Scheme48 or Go. There are some ways around that bootstrap problem.
That's what it does.
With Graal, it's possible to write a JVM in Java, but the JVM doesn't depend on another JVM to run, and the way it runs bytecode isn't the way it was compiled in the first place. It's not really self-hosted in the same way that a compiler can be.
It's like how PyPy is Python but with the asterisk that it's bootstrapped with RPython which is an almost-subset of python so that it doesn't require a runtime.
You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible.
But the JVM you build using your statically compilable Java subset can then run the Spring Framework or whatever.
How restrictive do you think the subset is? It only doesn't support some features you probably never wanted to use anyway, and arbitrary reflection. I maintain 125k lines of Java that conforms to the subset rules, and to be honest I never even think twice about the fact that it's a subset.
There are a couple of Java implementations written in Java, Jikes RVM being one of the first ones, almost 15 years ago.
BTW, how do you implement a garbage collector with a garbage-collected language?
You write it carefully so the garbage collector itself doesn't also need to allocate objects.
Here's a GC for Java written in Java https://github.com/oracle/graal/tree/master/substratevm/src/....
Java doesn't provide a primitive to deallocate memory. So while I can see how for instance allocation a huge chunk / big array could be allocated and you represent objects in there don't you end up with a situation where your process will always occupy a fixed amount memory? Might not need to be fixed. You might also be able to extend more but how would you free that again?
But you might find this interesting as a specific example - this is where it actually obtains memory from the OS.
https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b...
Note the @Uninterruptible annotation - that's saying that this code is safe to use within the GC itself. Notice how the file doesn't contain even a single 'new! (Outside of PosixVirtualMemoryProviderFeature, which is something else.)
You are writing a GC in Java, yes but have access to low-level memory abstractions/interfaces, right?
Whereas I was initially wondering how to write a GC in "pure Java" that doesn't have access to low-level memory interfaces.
Does it make sense why I was asking, now? Or am I still not getting it?
To be clear, Java the language is Java, I'm not going to argue that it's not Java because of special primitives / interfaces available to write the GC here, but it is not what most people would think of when considering the limitations of the runtime everyone's using.
I think I'd phrase it like this: you can write a GC mostly in Java.
Other GCs than the default Java one in native image like G1 actually embed the C++ version of the implementation instead of writing it in Java.
Yeah, but also the code shown above used native low level primitives like mmap which typically aren't available.
AOT, special behavior directives (@Uninterruptible), native memory access, making sure not to use new (?), at that point you are formally using Java, the language, but it's sort of its own thing.
So, that's still cool and likely no way around it but I wonder to what degree it's actually beneficial: Your program is much closer to a C++ program than a Java one except for syntax and the additional glue abstractions that typically exist in neither. In a (exaggerated) sense it's like it's written in a C++ DSL embedded in Java.
If you know how to write C++ it's possibly simpler to just write it in C++ as you know how memory management there works. If you know Java you need to get familiar to the extensions used here.
This is a bit different from the idea of self-hosting a compiler for instance where you can start writing your compiler now ideomatically in your own language instead of something different. For instance if your language & runtime has GC it's much simpler / safer to write a program in it, and so a compiler in it than pre-self-hosting (if the earlier compiler was written in C).
So what in particular is afforded by writing the GC in "Special Java" ? Is it just about being able to say "it's all in Java" or are there language features in "Special Java" that make live easier than C++? Or other benefits? For instance, I imagine use of the wider ecosystem / libraries isn't possible whereas in C++ it is (more so at least).
It would be nice if somehow you could write a GC itself in regular old Java without having to worry about aspects of how to do it in a special, restricted way. Say, the code you write and which runs the garbage collection creates objects, which subsequently get cleaned up by your very own GC program.
In the end you still have to work with low level abstractions / memory though and maybe that's still different to the self-hosted compiler example in a sense: There you translate code into a language that is more low level but you don't need to have these abstractions available in your own language / on your stage of computation / while running your compiler.
Native calls are a normal part of Java. And the pointer and word classes used could be implemented using the Unsafe class which is present in Java.
the gist is you treat memory as a big array, then write a program to manipulate that array. it's really just a decision about what you want to "take as primitive" in your implementation. could be brk, could be malloc and free, or something higher level.
My turn: NASDAQ moved from cpp to Java quite a few years ago. Do you think you know something they don't?
SweetHome 3D IS slower than competitive projects written in C++.
C++ tools tend to be faster than comparative Java tools because of fast startup time, no GC, and being the default choice for performance sensitive projects for decades.
C++ is definitively faster because of inherent advantages.
You appear to be jumping to the third based on the first which appears erroneous in argument even if you turned out to be correct. In actuality it appears that for most things in the same ballpark language choice isn't necessarily the only or even the most important factor. This is even more true for things where startup time is an inconsequential factor, with better GC that doesn't result in lengthy pauses, and where development time is a substantial limiting factor wherein being quicker to work with may result in more time available to improve other design choices yielding as good or better results.
By the way, the .NET CLR is AFAIK written in C++, like with Hotspot. It's not fully self-hosting.
It's a tricky process because HotSpot is highly performance sensitive code. People won't accept regressions just to convenience the JDK maintainers. Java meanwhile is deliberately a simple language to make it accessible for people, so you lose some low level techniques that are useful for performance. Nonetheless, GraalVM native image has proven that you can achieve HotSpot like performance with a JVM written in Java. However it requires a big change in the compilation model that isn't always appropriate.
Some of the reason is historical, and some has to do with warmup. Project Leyden and Graal's Native Image will help compile more Java AOT, allowing even more of the runtime to gradually be written in Java. It will take some time as it's not a top priority: it won't immediately deliver user-facing functionality, and most of the work on the JDK is already done in Java code anyway.
GraalVM is the evolution of MaximeVM, originally developed at SunLabs, also about 15 years ago.
I haven't looked at it for ages and looking at Wikipedia it seems dead, so curious if there is any newer attempts....
You're commenting on an article about a newer attempt?
> Oracle plans to contribute the most applicable portions of the GraalVM just-in-time (JIT) compiler and Native Image. Oracle does not currently intend to contribute the polyglot technologies supporting other languages such as Python, Ruby, R, and JavaScript. Additional details will follow in the coming months as we move forward through this process.
It would appear this is about making native image artifacts / distribution a first class citizen across all of Java - making it an alternative to uberjars + jvm for running/distribution. Ie native desktop apps and native binaries for servers?
Does that mean to run it you need another JVM to run it on top of? That sounds stupid... Maybe you need another VM just to run it on once, so it can translate itself to native code on the target?
GraalVM is the regular HotspotVM integrated with the GraalVM compiler (which is normally AOT compiled as a native library, but can be run as a JAR); it also supports tooling with the ability to compile code targeting the JVM to a native executable, as well as leveraging AOT compilation itself.
Graal reuses all the insanely good GC implementations, observability tools etc already present in OpenJDK (as throwing all that away would be stupid).
As pointed out by other comments, this concept of a "meta-circular VM" isn't new. It's been done before by two other projects, Maxine and Jikes. What's different about SubstrateVM is that this is a production tool rather than a research project, and it's not just a JVM, it's also a way to pre-initialize the app. Therefore programs compiled with native-image can start as fast as programs written in C. Actually, slightly faster in some cases. You may wonder how that's possible given that Java apps normally start slowly, but it's because there's no JIT compilation and the state of the heap is snapshotted, with classes pre-initialized including the JVM itself. So the program can literally just start executing at main() in machine code with no VM startup overhead, because it's done already.
The downside is that snapshotting and AOT consume a lot of disk space.
There are some questions below asking how this works. It sounds initially "impossible", like a lot of stuff GraalVM/Truffle does, but it's quite easy to understand really.
You start with a bytecode compiler written in Java. This is a normal program written in the normal way, because a compiler is ultimately just a function that converts one stream of bytes to another. Then you write the runtime and GC in Java too, and compile that as well. This code is a bit special. It's still syntactically Java, but, some classes and methods are given special meanings and some extra rules apply. They aren't compiled in the same way as normal Java code. For example you can write code like this:
UnsignedWord value = Pointer.readUnsignedWord(address)
Several other tricks are required. GC code can't allocate because it would mess up the heap it's working with, so you can use annotations to mark methods as "never access the heap". But then, GC code is written in Java and Java must allocate for almost anything non trivial, so how does that work? The answer is, the GC code is initialized at build time and all the objects it needs are snapshotted into the default heap that's mapped into memory at startup.
There are lots of other tricks, mostly annotations that control the compiler so that e.g. methods are guaranteed to be inlined and removed, objects are guaranteed to be stack allocated. This isn't available to normal Java but when you control the compiler it's not a problem. The advantage of this Java-superset (or subset) is that you can use all the normal tools that understand source code, like IntelliJ, JavaDoc etc.
Also, may I ask how do you know so much about the topic? I would really like to one day work on OpenJDK/Graal, but I just don’t see the road ahead me.. — I’ve just started my master in CS, but I don’t feel it closing the gap at all. Surely I can read up more and more on the topic in small steps, but I would be very grateful for any guidance/pointer.
How did I learn about it - mostly by reading their papers, watching their videos and asking lots of inane questions on their Slack. Also, I happen to live around the corner from where the Graal team work so occasionally I've been able to meet them in person and ask questions then. But mostly I just followed their efforts for a long time. I got interested in Graal back before most people had heard about it, after somehow randomly encountering a discussion of TruffleRuby on Chris Seaton's blog. Then I wrote about it here:
https://blog.plan99.net/graal-truffle-134d8f28fb69
Most of the Graal guys came out of masters and PhD programs at JKU Linz, so the path you're on is a well trodden one. I wouldn't feel down about it. For me, how it worked was quite mysterious for a long time and then one day it clicked, and I saw the essential simplicity behind the concept.
It's not uncommon to do a CS master Thesis as part of an internship, if your university allows that. We have plenty of topics to choose from and you can also come up with your own.
Good luck!
And (shameless self plug), implement a Truffle language. Start here: https://www.youtube.com/watch?v=pksRrON5XfU&list=PLN193mR3Js...
Anyway, OpenJDK is its own project with its own processes and culture, GraalVM was historically from a totally separate part of Oracle and adopted its own processes and development culture. This announcement doesn't change what tech is available, it's more about re-organizing how development is done. It doesn't really affect Java developers much, except that maybe now more stuff will come out of the box with a 'regular' JDK. Currently to get Graal technology you need to use their own custom spin of the JDK.
GraalVM is going to see adoption go up > 100x.
Oracle plans to contribute the most applicable portions of the GraalVM just-in-time (JIT) compiler and Native Image. Oracle does not currently intend to contribute the polyglot technologies supporting other languages such as Python, Ruby, R, and JavaScript.
It may not be hot and cool like some hip new language, but Java work is very important and quite literally makes the world work.