Substrate VM – A framework that allows AOT compilation of Java applications(github.com)
github.com
Substrate VM – A framework that allows AOT compilation of Java applications
https://github.com/graalvm/graal/tree/master/substratevm
14 comments
[deleted]
> 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).
Is there a way to test it without creating an Oracle account? The documentation leads me to http://www.oracle.com/technetwork/oracle-labs/program-langua..., which requires an account to download the files.
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?
that's most likely intentional, I'm sure Oracle has a lot of lawyers to look over this kind of stuff ;-)
It seems you are right and that they are very aware of which parts of the project are GPL2+classpath and which are not...
https://github.com/graalvm/graal/issues/269
https://github.com/graalvm/graal/issues/269
For those who has problem understanding relation between Graal and Substrate VM :
http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637...
Page 4.
http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637...
Page 4.
This is huge, congrats to the team! I hope it helps Substrate VM to get better adoption outside of Oracle.
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?
Yes, that is the long term goal.
Project Metropolis is about rewriting OpenJDK C++ parts in Java, so SubstrateVM needs to support all major OpenJDK targets.
Project Metropolis is about rewriting OpenJDK C++ parts in Java, so SubstrateVM needs to support all major OpenJDK targets.
What's the difference between substrate vm and jaotc?
https://mjg123.github.io/2017/10/02/JVM-startup.html
Substrate VM is more mature? jaotc was response to closed Substrate VM?
https://mjg123.github.io/2017/10/02/JVM-startup.html
Substrate VM is more mature? jaotc was response to closed Substrate VM?
`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.
FWIW, both use Graal as a compiler.
FWIW, both use Graal as a compiler.
I still remember the original submission, One VM to rule them All.
https://news.ycombinator.com/item?id=6232240
Gosh 4 years already.
Cant wait to see how TruffleRuby perform with SubstrateVM.
https://news.ycombinator.com/item?id=6232240
Gosh 4 years already.
Cant wait to see how TruffleRuby perform with SubstrateVM.
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. :)
So let me get this straight.
With Truffle i can get whatever prog lang abd compile it with Graal and either use with Graal VM or Substrate VM.
And i get what ? an executable which includes only what the program needs / uses ?
And i get what ? an executable which includes only what the program needs / uses ?
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.
> 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.
Thanks for the thorough explanation. I am curious how hard / time consuming is to reimplement the existing languages in Truffle.
> 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.
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.
At this stage how usable is all of this (graal/truffle etc) in real production ?
Twitter are using Graal in production right now and say it’s saving them real money. Truffle’s a bit earlier in development still.
With Substrate VM you get way faster startup for your Truffle language and potentially overall less dynamic footprint.
Graal VM is based on HotSpot, which is sort of "bloated" for the specific use case that Truffle has.
Graal VM is based on HotSpot, which is sort of "bloated" for the specific use case that Truffle has.
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.
Thanks for the explanation. Is this for Java only, or can it be used with all other languages that produce JVM bytecode?
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.
This is very exciting. Are JavaFx applications supported?
I don’t know how it’s implemented, but JNI works I believe.
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.
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.
Bazel is popular for Google employees.
Gradle is an enduring suffering for all Android developers, except the ones blessed with 16GB Xeons and SSDs.
None of them sound modern to me.
Specially Gradle, given my experience on Android development.
Gradle is an enduring suffering for all Android developers, except the ones blessed with 16GB Xeons and SSDs.
None of them sound modern to me.
Specially Gradle, given my experience on Android development.
>Bazel is popular for Google employees.
https://github.com/bazelbuild/bazel/wiki/Bazel-Users
Asana, Databricks, Dropbox, Pinterest, Stripe and Uber ATG are not Google.
https://github.com/bazelbuild/bazel/wiki/Bazel-Users
Asana, Databricks, Dropbox, Pinterest, Stripe and Uber ATG are not Google.
All of them irrelevant in the world of Java programming, hence why I wasn't even aware they were using Bazel.
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.
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.
[deleted]
I wonder how the performance and size of apps compiled with Graal compares with traditional Java apps ?
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.
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.
There was some discussion on HN about this VM before (about performance with TruffleRuby, an implementation of Ruby on the JVM): https://news.ycombinator.com/item?id=13652541
There was some discussion on HN about this VM before (about performance with TruffleRuby, an implementation of Ruby on the JVM): https://news.ycombinator.com/item?id=13652541
If you're interested, I gave a talk at RubyConf a couple months back with updated info for TruffleRuby on the SVM:
https://www.youtube.com/watch?v=hIMldcAzd5o
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.
https://www.youtube.com/watch?v=hIMldcAzd5o
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.
> only the part of the JRE and external libraries that the app really uses
Just curious, how the reflection and dynamic class loading things work when generating an executable?
Just curious, how the reflection and dynamic class loading things work when generating an executable?
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.
>> 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.
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.
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.
Yeah yeah lets abandon perfectly usable piece of technology because some john smith from the internet hates oracle.
> 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.
[1]https://www.computerworld.com/article/2857293/legal/oracle-a...
edit: changed to past tense: I had forgotten the supreme court refused the case, but that just means the argument hasn't been tested in the courts.
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.
[1]https://www.computerworld.com/article/2857293/legal/oracle-a...
edit: changed to past tense: I had forgotten the supreme court refused the case, but that just means the argument hasn't been tested in the courts.
I am not able to use random Java library from Maven central in Android thanks Google.
Thanks Google, only Java libraries written with Android Java in mind do actually work flawlessly in Android.
Forcing many of us to have either two versions of a Java library or resort to a common subset.
Yeah Google is not malicious at all.
Thanks Google, only Java libraries written with Android Java in mind do actually work flawlessly in Android.
Forcing many of us to have either two versions of a Java library or resort to a common subset.
Yeah Google is not malicious at all.
>> Given a viable choice between an Oracle project and a non-Oracle project, always go for the latter.
Why? Consider VirtualBox, Java, and MySql. Did anyone get in trouble for using these?
Why? Consider VirtualBox, Java, and MySql. Did anyone get in trouble for using these?
> Why?
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).
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).
Google infamously got in a ton of trouble for using Java since oracle wanted a slice of that pie.
There's a reason the MariaDB fork exists.
There's a reason the MariaDB fork exists.
>> 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.
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.
Rightly so, after they pulled a Microsoft into Java.
Now any Java developer writing libraries is forced to write Android specific versions thanks to how Google forked Java.
No 100% support for all JVM bytecodes, so no invokedynamic support. Cherry picked packages and classes from Java 6, 7 and 8.
It will only get worse with the current Java roadmap.
Now any Java developer writing libraries is forced to write Android specific versions thanks to how Google forked Java.
No 100% support for all JVM bytecodes, so no invokedynamic support. Cherry picked packages and classes from Java 6, 7 and 8.
It will only get worse with the current Java roadmap.
> 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.
1. https://www.cnet.com/news/apache-grouses-about-java-compatib...
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.
1. https://www.cnet.com/news/apache-grouses-about-java-compatib...
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.
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.
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.
Winning court cases doesn't necessarily mean justice was actually made.
It is all about who has the best lawyers that are able to influence the jury to achieve the goals of their clients.
The amount of US mistrials is a good example of it.
It is all about who has the best lawyers that are able to influence the jury to achieve the goals of their clients.
The amount of US mistrials is a good example of it.
ex-Sun team != Oracle execs
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.