This is awesome! Substrate VM not being open source was a major reason I wasn't more excited about Truffle/Graal. Without Substrate VM, startup times for Truffle-based interpreters are terrible (see http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-...).
Now anyone outside of Oracle can write cool JIT compilers using Truffle, and have them start quickly! I think it can also be used to compile normal Java programs to native executables.
So great. I was worried that Oracle would keep Substrate VM as a proprietary secret sauce, but that would have really torpedoed the potential of Graal.
> Substrate VM is a framework that allows ahead-of-time (AOT) compilation of Java applications under closed-world assumption into executable images or shared objects (ELF-64 or 64-bit Mach-O).
I might be misreading this, but it seems like most of SVM is not under Classpath exception (most of the files are missing the magic words), which implies SubstrateVM binaries must be GPL 2. Is this intentional?
Does Substrate VM have cross-platform support for major operating systems (i.e. for Linux, Windows, MacOS)? If so, can a binary compiled on MacOS run on Windows, and vice versa?
`jaotc` integrates with the HotSpot VM, while Substrate VM provides its own runtime (GC etc.) and intentionally supports only a subset of the JVM features.
Extremely happy to see this happen. I had played with a little Graal/Truffle language and tried using SVM when it was closed source, but ended up setting down the project (not really because of SVM, mind you). Maybe now I can restart it. :)
I'm not entirely sure what you're asking, so I'll split it in two parts and hope one of them is applicable.
> With Truffle i can get whatever prog lang abd compile it with Graal and either use with Graal VM or Substrate VM.
Truffle is basically a toolkit for building language runtimes. It provides a framework for creating AST interpreters. Generally AST interpreters are easy to work with and reason about, but slow. Truffle addresses the speed issue by using Graal's API to perform partial evaluation on the interpreter. So, you get very fast runtimes without having to build a custom VM. But, it also exposes some compiler details by way of an annotation-based DSL if you want to take advantage of it. This includes control for PIC sizes, loop exploding, and explicit branch profiling amongst others.
As a language toolkit, Truffle also gives you an instrumentation framework so you get things like a debugger and profiler for minimal effort. It provides a polyglot system so you can call into other Truffle languages. Since they all inherit from the same base Node class, the compiler can even inline nodes across language boundaries. Truffle takes advantage of that itself by shipping functionality, such as its own native function interface, as its own Truffle language.
> And i get what ? an executable which includes only what the program needs / uses ?
The SVM can be used to compile any Java program. Truffle-based language implementations are just Java programs. Compiling with the SVM allows you to build a statically linked native binary that contains your language runtime. Generally that binary will have improved startup time, ease distribution issues, and so on. The SVM links in Graal, so you get all that without sacrificing peak performance.
> I am curious how hard / time consuming is to reimplement the existing languages in Truffle.
We focus on getting really high performance from our Truffle languages, so we often forget to emphasise this point: Truffle is the easy way to create languages, as well as the high performance way. Truffle uses the AST pattern, which is how an undergraduate would implement an interpreter after one compilers course. And you can get 90% of the high performance from a simple interpreter, and then work on it a bit more to get the remaining 10% when you find you need it.
I haven't touched java in years, but have known this existed. How does it compare to some of the features added in recent versions of java that do similar stuff?
The AOT in the OpenJDK? It actually uses the same compiler, Graal, under the hood. But SubstrateVM is another level - it produces a single statically linked binary of your Java program - no JVM needed on your system or included in the binary. It's all written in Java - the GC and everything.
It works on JVM bytecode in classfiles and doesn't have an opinion on where it came from. Some JVM languages may be more likely to use features that aren't supported though, like reflection on classes you haven't annotated. I think we've used it on Kotlin and Scala at least.
my biggest peeve is graal/substrate creating and using its own build tooling - for example mx (written in python) to do the build and compilation.
Graal itself uses mx.
I would wish they would use something far more popular and common like Bazel or even Gradle. TBH, mx predates all of these .... but its time to use modern tooling.
There are 13 references to building java projects on that page.
I really don't want to get into a flamewar on this, but Bazel does have a lot of traction and is used in many wildly popular tools like Tensorflow. It would be nice to have that here as well.
Graal can be used with "traditional" HotSpot, in which case the user would observe no particular difference in (download/disk) sizes.
But this article is about SubstrateVM, which is a JVM that links itself with the program being run and throws out the rest. You can get very small program sizes this way, comparable to Go.
Both app size and startup time should improve greatly with Graal (or with Java 9's jlink or jaotc), the idea is to generate an executable with only the part of the JRE and external libraries that the app really uses.
The SVM is a critical component in achieving some of our performance objectives for TruffleRuby, particularly when it comes to startup time and running code that hasn't warmed up yet. Short-lived applications have always been something of an Achilles heel for dynamic languages targeting the JVM. The SVM provides a nice way of solving that problem as long as your program can operate with its restrictions (e.g., no dynamic class loading).
From a positioning perspective, I think an interesting aspect of the SVM is TruffleRuby is no longer an implementation of Ruby on the JVM. It's an implementation of Ruby written in Java for sure, but the JVM isn't required.
The native image generator performs a closed-world static analysis over your application, the JDK, and any supplied libraries to determine what's actually in use. In cases of ambiguity, it must be conservative and include all candidate classes. Since the output is a native binary without the JVM (and subsequently, without a Java bytecode interpreter), there's no way to dynamically load classes. Reflection is handled by registering classes during the image generation process, I believe. Static MethodHandles neatly avoid any issues as well, if you can work with that.
FOSS community (or anyone else for that matter) shouldn't touch anything coming out of Oracle with a bargepole. Given the level of maliciousness, their Open Source work should be considered a minefield.
> Yeah yeah lets abandon perfectly usable piece of technology because some john smith from the internet hates oracle
It's doesn't need to be hate, anyone concerned about the well-being of this industry should be wary of being an enabler/complicit. Oracle is actively malicious: remember this is the company that was actively trying to make API's copyrightable[1]. How many APIs do you use in a day do you think such a ruling would have impacted? You wouldn't be able to have drop-in replacement libraries (or web-services). Hell, it would have made it illegal to fork an open source project unless you got the copyright to the API as well.
Given a viable choice between an Oracle project and a non-Oracle project, always go for the latter.
>> Google infamously got in a ton of trouble for using Java since oracle wanted a slice of that pie.
They sure did, by... being reckless, and possibly stupid. You can use OpenJDK (and bazillions people do), and noone will bother you.
But if you get something trademarked "Java", and then change it to your liking, and you still call it "Java", and release it under trademarked name, then you do deserve the lawsuit & c.
> Now any Java developer writing libraries is forced to write Android specific versions thanks to how Google forked Java.
This is inaccurate. The Apache Project (Harmony) forked Java in the Sun days and Sun refused[1] to provide the compatibility tests (JCK) in order to prove that Harmony was Java. Google adopted the pre-forked Apache Harmony because Sun, in its brilliance, decided that J2ME and only J2ME was to be allowed on mobile. Incidentally, Oracle supported Apache Harmony before buying Sun, unsurprisingly Oracle changed their tune when they became custodians of Java and bribed/negotiated with IBM for IBM to recant its support for Harmony.
Google the "Do no Evil" company, decided to scumm Sun as proven by Andy Rubin's emails instead of playing by the book like everyone else in the Java eco-system.
Now every Java developer that wants to target Android needs to write Android Java, instead of pure Java.
> Google the "Do no Evil" company, decided to scumm Sun...
A jury looked at the evidence, heard the arguments, and disagreed with you. The decision held on appeal.
An alternative interpretation of historical events: had Sun (and Oracle) provided Apache Harmony with the JCK from then, Harmony wouldn't have fallen behind.
Uhm, for the reasons I stated, that Oracle doesn't mind if our industry implodes in return of a $1bn API copyright payout. Is that the sort of attitude you want to reward with your mindshare?
If the above concern isn't cogent to you, then perhaps their poor custodianship of other open source projects might convince you instead (Open Office and OpenSolaris).
>> their Open Source work should be considered a minefield.)
Well, any license can be a minefield. E.g. FB React had some questionable license... (they changed it) and so on. Indeed, one should check a license before using a product.
Meantime, is Oracle that bad?
I mean, people have been using VirtualBox, Java (OpenJDK), MySql, MySqlWorkbench, NetBeans, maybe more. All of those provided by Oracle with no fee required, and a liberal license. And, I do not see people being sued by Oracle over those.
I think Oracle's push into cloud is changing their approach. If only because a) Java is still slightly more than half of the enterprise app workload (the rest is .NET), b) those customers like opensource because it gives them options.
Right now it's a buyer's market and Oracle are way behind AWS, Azure and GCP, with Alibaba trying to smash through the side door.
Which is another thing. Oracle went on a hiring spree and pulled people from the other three willy-nilly. A large fraction of whom will have never really been fans of the classical Oracle way of doing things.
Now anyone outside of Oracle can write cool JIT compilers using Truffle, and have them start quickly! I think it can also be used to compile normal Java programs to native executables.
So great. I was worried that Oracle would keep Substrate VM as a proprietary secret sauce, but that would have really torpedoed the potential of Graal.