15 ms·

Java on Truffle – Going Fully Metacircular

242 points by Borkdude 6y ago

dboreham 6y ago
It would be helpful to include a short description of what this Truffle is, or at least a link to here https://www.graalvm.org/graalvm-as-a-platform/language-implementation-framework/ https://www.graalvm.org/graalvm-as-a-platform/language-imple... to disambiguate vs the probably better known smart contract development framework with the same name.
- emmanueloga_ 6y ago
  Just one data point, but I did know about Graal/Truffle, but not about the smart contract development framework with the same name [1] :-) 1: https://www.trufflesuite.com/ https://www.trufflesuite.com/
  - fiddlerwoaroof 6y ago
    Yeah, I’ve known about Graal/Truffle for years, and just heard about the smart contract thing today.
    - deleted 6y ago
      [deleted]
    - brabel 6y ago
      Same here. I suppose that if you're into the JVM, you'll know about Graal/Truffle... if you're into blockchain, you'll know about this other thing.
- hiimtroymclure 6y ago
  not sure why you were downvoted. I instantly thought of Truffle as it relates to smart contract work as well
  - Paradigma11 6y ago
    same.
- chrisseaton 6y ago
  Note that Oracle were using the name for their language framework for years before the blockchain people also started using it, and also had peer reviewed publications using it... do people not Google potential names before picking one?
vnorilo 6y ago
Truffle works by taking your interpreter and generating a compiler by partial evaluation [1]. So I believe they have written a JVM bytecode interpreter and Truffle makes the JIT. I'm super impressed by how the Truffle/GraalVM team has been able to turn this theoretical concept into a system that yields production grade compilers (although this Java on Java is not there yet). "A very important detail of this implementation is that it’s implemented in Java. Java on Truffle is Java on Java! Self-hosting is the holy grail of Java virtual machine research and development." - now if you chuckled and imagined this as xkcd, I'm with you. Regardless I think this is really not some ultimate geek olympics fantasy, but that truffle and graal will be equally if not more transformative to PL reseaech than LLVM has been. 1: http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f...
- KMag 6y ago
  High-performance JITs via partial evaluation of interpreters is the impressive part. Self-hosting Java isn't a huge deal. IBM's Jalapeno/JikesRVM has been a JVM implemented almost entirely in Java for decades. It self-compiles by using the highest tier of its JIT on itself and then dumps the native code in memory to disk as an executable. Though, as far as I know, JikesRVM doesn't keep around its own bytecode (or an SSA representation of itself) for later dynamically re-optimizing itself or inlining parts of the JVM in user code hot spots. Hopefully a Truffle/Graal-based production JVM would be able to dynamically re-optimize/inline almost all of the JVM into hot spots in user code.
  - mukel 6y ago
    Java on Truffle is a normal Java application, it can run on a vanilla OpenJDK, doesn't need the bootstrap step. Currently Graal/Truffle implements the first Futamura projection: you give it an interpreter written in Java, it automatically generates a compiler (JIT). In this mode we have to keep the interpreter IR graphs (blueprints) around for partial evaluation. With the first Futamura projection: Partial evaluator + interpreter + user code. There's active work on implementing the second Futamura projection, where you partial evaluate the partial evaluator with respect to the interpreter, generating a specialized partial evaluator for that interpreter. With the second Futamura projection: (Specialized partial evaluator + interpreter) + user code. This is truly fascinating and beautiful and the fact that it works for Java and not just a toy academic prototype is mind-blowing.
TimTheTinker 6y ago
This is fascinating. Combined with all the other languages that are now supported, along with its incredible capabilities, GraalVM is shaping up to be a truly modern “common language runtime” — what the .NET CLR and DLR once promised to be but so far have failed to deliver. And for what it’s worth, TruffleRuby on Truffle/GraalVM (reportedly derived from JRuby) is supposed to be incredibly fast.
- dehrmann 6y ago
  I could see GraalVM being a part of whatever replaces Docker.
  - pjmlp 6y ago
    Most of the stuff people use Docker for, I was already doing in 2006 with WebSphere and EAR "images".
    - matsemann 6y ago
      No, it was miserable as f and no way comparable. Getting WAS to run locally could take a day or two of configuring. And since everything was manually done and had to be tweaked when loading in new stuff. And if you broke something (or it broke by itself) it was easier to just wipe it and reinstall everything from scratch, again wasting a few days of work. And if you tried running your own EAR files, it could take an hour from a code change to actually test it. Building it, installing it, reloading the server, and then getting to the correct state of testing. If you discovered a bug, you had to patch the code, build the file again and start over, wasting another hour. Some of it was evaded by using JRebel, but if the changes couldn't be swapped you were SOL. No way WAS+EAR can be compared to running stand-alone images. It was a clusterfuck of dependencies and dependent configuration.
      - a_imho 6y ago
        My experience with running images on k8s is way worse than what you describe. It is a clusterfuck of dependencies and configuration when in reality people just want to run java -jar.
jijji 6y ago
although running a jvm inside of a jvm sounds fun, wouldn't this slow down an already slow interpreted application?
- dehrmann 6y ago
  Yes, but modern Java isn't really interpreted.
  - danielscrubs 6y ago
    “An interpreted language is a type of programming language for which there is an interpreter which runs over a virtual machine“ I get what you are trying to say but if (!) you use JVM you are using an interpreter.
    - rwoerz 6y ago
      According to this definition, C is an interpreted language because "there is" CINT. [1] [1] https://web.archive.org/web/20190911160010/http://www.hanno.jp/gotom/Cint.html https://web.archive.org/web/20190911160010/http://www.hanno....
      - danielscrubs 6y ago
        Wikipedias definition. And yes indeed!
    - chrisseaton 6y ago
      > but if (!) you use JVM you are using an interpreter You're using an interpreter to start with, but then it dynamically compiles machine code to run instead of using the interpreter. But these terms are very fluid. I'd call HotSpot an interpreter, and a compiler, and both at the same time. It depends how you're looking at it at that moment.
- mukel 6y ago
  Running on HotSpot is an advantage for the development of Java on Truffle itself; the tooling is amazing, debugger, inspectability, you can debug the VM as a normal Java application... GraalVM can compile an AOT version of Java on Truffle, then no JVM is needed.
yc12340 6y ago
This is wonderful news, but Graal is sadly behind the times there. Android had AOT compilation of Java bytecode (well, technically Dalvik bytecode) since 2013. It was upgraded to hybrid AOT/JIT mode in 2016. All of it was open-sourced, unlike Graal, where many key optimizations (such as auto-vectorization) remained proprietary. Unlike GraalVM's AOT mode, Android VM can run existing Java libraries without any code changes — you don't have to painstakingly look for static variables and mark them for late loading, and reflection just works.
- suyash 6y ago
  If you're comparing Android with Graal, you don't understand what Graal is all about.
- pjmlp 6y ago
  You are the one behind the times, Java has had support for AOT compilation since around 2000, just not as free beer. Most 3rd party commercial JDKs have offered it, specially for embedded deployment scenarios. Besides Android Java isn't Java, rather a Google dialect with cherry picked packages from (nowadays) OpenJDK, most likely to die frozen in its current state as they embrace Kotlin über alles.
- kaba0 6y ago
  AOT is not by itself anything good/fancy. As others mentioned, java could be AOT compiled since ancient times. Graal is state of the art/interesting, because it uses a different compilation technique than usual, looking at the program to be compiled incorporated with the interpreter for that compilation - which result in superior results for AOT compilation, and in the case of a replacement of JIT compilers, it looks promising (but not yet surpassing Hotspot). Android’s java is pretty terrible in comparison, just saying.
- deleted 6y ago
  [deleted]
dehrmann 6y ago
I'm still impressed by the amount of crazy-impressive tooling the Java ecosystem has compared to other languages.
- divs1210 6y ago
  correction: > other mainstream languages
  - saagarjha 6y ago
    Are there non-mainstream languages with more tooling? Seems like it would be a bit surprising if there were…
    - pjmlp 6y ago
      I guess they meant Smalltalk and Common Lisp commercial endeavours of the 90's. And indeed, there are a couple of things that Java and .NET still don't do.
      - erik_seaberg 6y ago
        It sounds like Sun acqui-hired some people who worked on Self and Strongtalk to get those ideas into the HotSpot JVM: https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk
        pjmlp 6y ago
        They did, some of them went to work on V8 and Dart 1.0 VM afterwards.
- hajile 6y ago
  I’m more impressed that they still think XML is great for project configuration .
  - 6y ago
pestatije 6y ago
Very impressive, good news for programming language research. On the other hand, it seems to me that these efforts and its resources would be better used developing a Webasm JVM implementation. Or at least kick-start the project. We are missing a major platform in the JVM ecosystem and nobody seems to care.
- lsuresh 6y ago
  There's already GraalVM Wasm: https://www.graalvm.org/reference-manual/wasm/ https://www.graalvm.org/reference-manual/wasm/
  - hackcasual 6y ago
    That's GraalVM targeting WASM, not JVM on top of WASM. I suspect some level of GC support will be needed in WASM for good performance
    - moonchild 6y ago
      I assume the GP was referring to wasm running on top of graal, not graal running on top of wasm. I don't think graal atop wasm would be a particularly interesting use case. Wasm purports to be a portable, secure, performant application runtime. Graal purports to be a portable, secure , performant application runtime. The latter, however, has had many more engineer-hours thrown at its implementation, and is thus both more heavyweight (so it needs all the resources it can get) and more performant (so it makes sense to use it as the backing runtime).
      - pawelmurias 6y ago
        Wasm is build as an efficient target for C/C++ like languages. It's mostly a striped down portable CPU intruction set. Graal/Truffle is intended to be an efficient target for everything. It's a toolbox of crazy magic for building your own JIT. There are not equivalent.
        6y ago
fniephaus 6y ago
Espresso's README.md contains some interesting details, for example: > ... it already passes >99.99% of the Java Compatibility Kit ... > Running HelloWorld on three nested layers of Espresso takes ~15 minutes. Link: https://github.com/oracle/graal/tree/6dd83cd94763b8736b42063f3cbf288b8add4128/espresso#espresso-coffee https://github.com/oracle/graal/tree/6dd83cd94763b8736b42063...
- pulse7 6y ago
  Regarding performance: "Note that current raw performance of Java on Truffle isn’t representative of what it will be capable of in the near future. The peak performance is several times lower than running the same code in the usual JIT mode. The warmup also hasn’t been optimized yet. We focused in this initial release entirely on the functionality, compatibility, and making Java on Truffle open source available for a broader community. ... Expect performance, both warmup and peak performance to increase rapidly in each of our upcoming 21.x releases."
- JackFr 6y ago
  > Running HelloWorld on three nested layers of Espresso takes ~15 minutes. It’s like how time works in “Inception”.
emmanueloga_ 6y ago
First thing, I think Graal/Truffle is really cool tech. Second thing... what's the story when it comes to Truffle licensing? :-) Would Oracle control the implementation of a particular language that used Truffle? Could they decide to "deplatform" that language? ("we don't authorize the use of Truffle in language implementation X for Y reasons") Or charge for licenses for users of that language? Or other somber scenarios... according to current licensing or in a hypothetical future ... Compare with, say, LLVM infrastructure, were it seems more certain that a language can be implemented as free software and with less restrictions or caveats.
- suyash 6y ago
  GraalVM is open source project
  - nextaccountic 6y ago
    This didn't stop Oracle from suing Google about Java APIs.
    - johnnycerberus 6y ago
      Google deserved it. They took the APIs out from the commercial implementation.
    - jolux 6y ago
      Google wasn't copying from OpenJDK.
    - kaba0 6y ago
      Java wasn’t open-source at the time Google copied it. In fact, the only thing that was prohibited by Sun’s license was mobile usage - they wanted to make money on Java with it. So Google should get sued to hell for blatantly copying it (and they are really bad at shepharding, just look at the state of android java vs openjdk)
      - pwdisswordfish5 6y ago
deleted 6y ago
[deleted]
ivanb 6y ago
Java livecoding now doesn't look all that out of reach.
- fniephaus 6y ago
  I agree! Our work on TruffleSqueak [1] and on Polyglot Live Programming [2] has shown that it's possible to build language-agnostic live programming tools with GraalVM. If Espresso implements the required Truffle APIs correctly, our tools should also just work for Java. :) [1] https://github.com/hpi-swa/trufflesqueak/ https://github.com/hpi-swa/trufflesqueak/ [2] https://github.com/hpi-swa/polyglot-live-programming https://github.com/hpi-swa/polyglot-live-programming
pulse7 6y ago
This is cool for former Smalltalkers: "Advanced class redefinition" (there was previous attempt at http://dcevm.github.io/ http://dcevm.github.io/ to bring this to HotSpot, but Sun/Oracle decided not to increase HotSpot complexity - see https://openjdk.java.net/jeps/159 https://openjdk.java.net/jeps/159). So it seems JVM is one step closer to the Smalltalk VM...
- brodo 6y ago
  This kind of stuff used to work in Objective-C too, but it was removed step by step for performance reasons. If you allow it, for every call you do to such an object you have to first check if the method exits on it or somewhere up the inheritance chain. You can cache of course, but adding or removing a method to an object invalidates the cache for the object itself and everything that inherits from it's class.
  - pulse7 6y ago
    In debugging mode it can work a bit slower and allow all this...
  - drkrab 6y ago
    In a modern JIT with dynamic decompilation you can do these things in place, because the compiler essentially has global knowledge. The only real issue is to define the semantics (and then implement it of course). Objective-C is AOT compiled so the runtime checks are needed all the time.
  - saagarjha 6y ago
    I'm not sure why you think it's been removed? The entire runtime is still there…the cache you're talking about still exists and is hit for every method call.
    - brodo 6y ago
      I wanted to do method swizzling in Objective C around 10 years ago. The methods for removing/replacing selectors where deprecated around that time.
pulse7 6y ago
How is Java on Truffle related to Substrate VM (https://www.graalvm.org/reference-manual/native-image/SubstrateVM/ https://www.graalvm.org/reference-manual/native-image/Substr...). Isn't Substrate VM also implemented in Java?
- sradman 6y ago
  Substrate is the key component that enables Ahead-of-Time compiled Native Images [1] on GraalVM. Java on Truffle enables bytecode to be dynamically loaded in a Native Image. Before Java on Truffle, you had to choose either pure compiled or pure dynamic. [1] https://www.graalvm.org/reference-manual/native-image/ https://www.graalvm.org/reference-manual/native-image/
  - vips7L 6y ago
    Which is completely amazing considering how much dynamic and reflective code there is floating around in the Java ecosystem. I've never been able to compile anything beyond a trivial app with native-image because there is always something dynamic being used somewhere. I'm really looking forward to seeing where espresso goes.
    - kaba0 6y ago
      I think reflection works with GraalVM native compile - the only catch is that the set of classes to be inspected by it should be known beforehand.
      - pulse7 6y ago
        This means you can't load JARs at runtime with ClassLoader in GraalVM natively compiled image...
        kaba0 6y ago
        Yes. But for longer running apps you are probably better off with a JVM since it will have better peak performance.
grashalm 6y ago
GraalVM dev here. Note that Java on Truffle is fully Open Source and available on Github. If you can read Java code and you are interested in how it is implemented start reading here: https://github.com/oracle/graal/blob/espresso/espresso/src/com.oracle.truffle.espresso/src/com/oracle/truffle/espresso/nodes/BytecodeNode.java#L634 https://github.com/oracle/graal/blob/espresso/espresso/src/c... If you are interested in a deep dive into the Truffle technology and are interested in why it makes sense to implement a language on top ofTruffle checkout my recent Rebase talk for a really long answer: https://youtu.be/O4icaN9khp4 https://youtu.be/O4icaN9khp4 If you don't have enough time for an 1h talk checkout my summary tweet: https://twitter.com/grashalm_/status/1212763944043139072 https://twitter.com/grashalm_/status/1212763944043139072
- grashalm 6y ago
  Also join us on Slack if you have questions: https://www.graalvm.org/slack-invitation/ https://www.graalvm.org/slack-invitation/
- jarym 6y ago
  Hey, I absolutely love Graal and where it is going. Big problem for me has been the license: GPLv2+CPE. On its own this is not a problem but coming from Oracle it makes people nervous. I think if there's ever room to move towards Apache 2 or similar license it would be really welcome.
  - deleted 6y ago
    [deleted]
  - pwdisswordfish5 6y ago
    There's no reason to think that you're safe even if it were Apache-licensed. One of the things that was made clear in Oracle v. Google is that Oracle effectively treats litigation as an essential expense for exploring all revenue sources, leaving others susceptible to suits whether they have merit or not. Compounding this latter concern was that another thing made clear is that the terms of the respective licenses is something that Oracle doesn't consider important. Refer to McNealy testifying for example that commercial use of even GPL-licensed work is prohibited (despite the terms of the license not supporting this stance).
geokon 6y ago
I'm not super familiar with the ecosystem, but does the GraalVM compiler provide a way to "tree shake" dependencies? This past year I wrote a rather simple desktop app (JavaFX) for work using Clojure. But Java by default uses RTTI - and Clojure by extension does as well - the dependency tree would balloon my final executable. For instance, I'd bring in some CV library like BoofCV to do some very basic image manipulation, but all of BoofCV and its dependencies would get dragged in. Hundreds of megabytes of junk.. So you either have to just accept you have a gargantuan executable or you have to use some smaller subpar libraries to do what you want. But it seems unfortunate the ecosystem pushes you to use less/smaller dependencies instead of using robust large ones. I understand the reason behind it. The java compiler has no way to ensure which classes will be used and which won't be b/c crazy things can happen at run time. Maybe with all the work on GraalVM people will move their libraries to not use RTTI as much? I haven't had a chance to hook up Graal yet (I think it doesn't play nice with JavaFX.. or maybe that's old news) - but it's unclear if it'll slim down the final binary. If it does - then this potentially a game changer for "deliverable" executables :) PS: You can manually go in and disable sub-dependencies.. but it's ugly and incomplete. I got Clojure/JFX/Java to compile down to something like 60MB - but my app is simple and it really should be more like 2MB.
- chrisseaton 6y ago
  > I'm not super familiar with the ecosystem, but does the GraalVM compiler provide a way to "tree shake" dependencies? Yes it does whole-world analysis and only compiles in classes, methods, and fields, which are actually used. The executables do have a minimum size, because the GC code for example doesn't get any smaller, but I think 2 MB is around the area of what can be achieved, yes.
- Chris2048 6y ago
  Is there more terminology that means "to tree-shake"? I understand javascript does tree-shaking, mainly in the context of code-minifiers, and certain languages do "path optimisation" usually at runtime - but I'm not sure how to describe the removal, and modification[0] of code (say, interpreted code) outside JS. I'd like to "tree-shake" python in order to see what % of code in it's deps is actually used. [0] e.g removing static parameters, replacing fns with lots of cases into multiple fns etc.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
ksec 6y ago
So someday I will be able to Run the whole Stack, Java ( Elasticsearch ), Ruby ( Rails ) , Javascript, and C all on top of GraalVM?
foolinaround 6y ago
What are some immediate (and also long term) practical applications of this advancement?
- mukel 6y ago
  The goal is not to compete, but rather complement HotSpot/GraalVM with: - (Polyglot) scripting with Java - Augmenting native images e.g. native javac with instant startup + annotation processors (very dynamic) running on Espresso - A simple non-invasive JVM for constrained environments - DCEVM-like features for developers - Approachable academic playground - Fast prototyping of JVM features e.g. it took our intern just two weeks to implement invokedynamic/MethodHandles
StephanRauh 6y ago
I wonder which use cases Espresso has. Until now, it looks like a very tech-focus project. That's fine, no doubt about that. But I guess there are business use-cases, too. Any ideas?

242 points by Borkdude 6y ago

It would be helpful to include a short description of what this Truffle is, or at least a link to here https://www.graalvm.org/graalvm-as-a-platform/language-implementation-framework/ https://www.graalvm.org/graalvm-as-a-platform/language-imple... to disambiguate vs the probably better known smart contract development framework with the same name.

emmanueloga_ 6y ago
Just one data point, but I did know about Graal/Truffle, but not about the smart contract development framework with the same name [1] :-) 1: https://www.trufflesuite.com/ https://www.trufflesuite.com/
- fiddlerwoaroof 6y ago
  Yeah, I’ve known about Graal/Truffle for years, and just heard about the smart contract thing today.
  - deleted 6y ago
    [deleted]
  - brabel 6y ago
    Same here. I suppose that if you're into the JVM, you'll know about Graal/Truffle... if you're into blockchain, you'll know about this other thing.
hiimtroymclure 6y ago
not sure why you were downvoted. I instantly thought of Truffle as it relates to smart contract work as well
- Paradigma11 6y ago
  same.
chrisseaton 6y ago
Note that Oracle were using the name for their language framework for years before the blockchain people also started using it, and also had peer reviewed publications using it... do people not Google potential names before picking one?

vnorilo 6y ago

Truffle works by taking your interpreter and generating a compiler by partial evaluation [1]. So I believe they have written a JVM bytecode interpreter and Truffle makes the JIT. I'm super impressed by how the Truffle/GraalVM team has been able to turn this theoretical concept into a system that yields production grade compilers (although this Java on Java is not there yet). "A very important detail of this implementation is that it’s implemented in Java. Java on Truffle is Java on Java! Self-hosting is the holy grail of Java virtual machine research and development." - now if you chuckled and imagined this as xkcd, I'm with you. Regardless I think this is really not some ultimate geek olympics fantasy, but that truffle and graal will be equally if not more transformative to PL reseaech than LLVM has been. 1: http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f...

KMag 6y ago
High-performance JITs via partial evaluation of interpreters is the impressive part. Self-hosting Java isn't a huge deal. IBM's Jalapeno/JikesRVM has been a JVM implemented almost entirely in Java for decades. It self-compiles by using the highest tier of its JIT on itself and then dumps the native code in memory to disk as an executable. Though, as far as I know, JikesRVM doesn't keep around its own bytecode (or an SSA representation of itself) for later dynamically re-optimizing itself or inlining parts of the JVM in user code hot spots. Hopefully a Truffle/Graal-based production JVM would be able to dynamically re-optimize/inline almost all of the JVM into hot spots in user code.
- mukel 6y ago
  Java on Truffle is a normal Java application, it can run on a vanilla OpenJDK, doesn't need the bootstrap step. Currently Graal/Truffle implements the first Futamura projection: you give it an interpreter written in Java, it automatically generates a compiler (JIT). In this mode we have to keep the interpreter IR graphs (blueprints) around for partial evaluation. With the first Futamura projection: Partial evaluator + interpreter + user code. There's active work on implementing the second Futamura projection, where you partial evaluate the partial evaluator with respect to the interpreter, generating a specialized partial evaluator for that interpreter. With the second Futamura projection: (Specialized partial evaluator + interpreter) + user code. This is truly fascinating and beautiful and the fact that it works for Java and not just a toy academic prototype is mind-blowing.

TimTheTinker 6y ago

This is fascinating. Combined with all the other languages that are now supported, along with its incredible capabilities, GraalVM is shaping up to be a truly modern “common language runtime” — what the .NET CLR and DLR once promised to be but so far have failed to deliver. And for what it’s worth, TruffleRuby on Truffle/GraalVM (reportedly derived from JRuby) is supposed to be incredibly fast.

dehrmann 6y ago
I could see GraalVM being a part of whatever replaces Docker.
- pjmlp 6y ago
  Most of the stuff people use Docker for, I was already doing in 2006 with WebSphere and EAR "images".
  - matsemann 6y ago
    No, it was miserable as f and no way comparable. Getting WAS to run locally could take a day or two of configuring. And since everything was manually done and had to be tweaked when loading in new stuff. And if you broke something (or it broke by itself) it was easier to just wipe it and reinstall everything from scratch, again wasting a few days of work. And if you tried running your own EAR files, it could take an hour from a code change to actually test it. Building it, installing it, reloading the server, and then getting to the correct state of testing. If you discovered a bug, you had to patch the code, build the file again and start over, wasting another hour. Some of it was evaded by using JRebel, but if the changes couldn't be swapped you were SOL. No way WAS+EAR can be compared to running stand-alone images. It was a clusterfuck of dependencies and dependent configuration.
    - a_imho 6y ago
      My experience with running images on k8s is way worse than what you describe. It is a clusterfuck of dependencies and configuration when in reality people just want to run java -jar.

jijji 6y ago

although running a jvm inside of a jvm sounds fun, wouldn't this slow down an already slow interpreted application?

dehrmann 6y ago
Yes, but modern Java isn't really interpreted.
- danielscrubs 6y ago
  “An interpreted language is a type of programming language for which there is an interpreter which runs over a virtual machine“ I get what you are trying to say but if (!) you use JVM you are using an interpreter.
  - rwoerz 6y ago
    According to this definition, C is an interpreted language because "there is" CINT. [1] [1] https://web.archive.org/web/20190911160010/http://www.hanno.jp/gotom/Cint.html https://web.archive.org/web/20190911160010/http://www.hanno....
    - danielscrubs 6y ago
      Wikipedias definition. And yes indeed!
  - chrisseaton 6y ago
    > but if (!) you use JVM you are using an interpreter You're using an interpreter to start with, but then it dynamically compiles machine code to run instead of using the interpreter. But these terms are very fluid. I'd call HotSpot an interpreter, and a compiler, and both at the same time. It depends how you're looking at it at that moment.
mukel 6y ago
Running on HotSpot is an advantage for the development of Java on Truffle itself; the tooling is amazing, debugger, inspectability, you can debug the VM as a normal Java application... GraalVM can compile an AOT version of Java on Truffle, then no JVM is needed.

yc12340 6y ago

This is wonderful news, but Graal is sadly behind the times there. Android had AOT compilation of Java bytecode (well, technically Dalvik bytecode) since 2013. It was upgraded to hybrid AOT/JIT mode in 2016. All of it was open-sourced, unlike Graal, where many key optimizations (such as auto-vectorization) remained proprietary. Unlike GraalVM's AOT mode, Android VM can run existing Java libraries without any code changes — you don't have to painstakingly look for static variables and mark them for late loading, and reflection just works.

suyash 6y ago
If you're comparing Android with Graal, you don't understand what Graal is all about.
pjmlp 6y ago
You are the one behind the times, Java has had support for AOT compilation since around 2000, just not as free beer. Most 3rd party commercial JDKs have offered it, specially for embedded deployment scenarios. Besides Android Java isn't Java, rather a Google dialect with cherry picked packages from (nowadays) OpenJDK, most likely to die frozen in its current state as they embrace Kotlin über alles.
kaba0 6y ago
AOT is not by itself anything good/fancy. As others mentioned, java could be AOT compiled since ancient times. Graal is state of the art/interesting, because it uses a different compilation technique than usual, looking at the program to be compiled incorporated with the interpreter for that compilation - which result in superior results for AOT compilation, and in the case of a replacement of JIT compilers, it looks promising (but not yet surpassing Hotspot). Android’s java is pretty terrible in comparison, just saying.
deleted 6y ago
[deleted]

dehrmann 6y ago

I'm still impressed by the amount of crazy-impressive tooling the Java ecosystem has compared to other languages.

divs1210 6y ago
correction: > other mainstream languages
- saagarjha 6y ago
  Are there non-mainstream languages with more tooling? Seems like it would be a bit surprising if there were…
  - pjmlp 6y ago
    I guess they meant Smalltalk and Common Lisp commercial endeavours of the 90's. And indeed, there are a couple of things that Java and .NET still don't do.
    - erik_seaberg 6y ago
      It sounds like Sun acqui-hired some people who worked on Self and Strongtalk to get those ideas into the HotSpot JVM: https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk
      - pjmlp 6y ago
        They did, some of them went to work on V8 and Dart 1.0 VM afterwards.
hajile 6y ago
I’m more impressed that they still think XML is great for project configuration .
- 6y ago

pestatije 6y ago

Very impressive, good news for programming language research. On the other hand, it seems to me that these efforts and its resources would be better used developing a Webasm JVM implementation. Or at least kick-start the project. We are missing a major platform in the JVM ecosystem and nobody seems to care.

lsuresh 6y ago
There's already GraalVM Wasm: https://www.graalvm.org/reference-manual/wasm/ https://www.graalvm.org/reference-manual/wasm/
- hackcasual 6y ago
  That's GraalVM targeting WASM, not JVM on top of WASM. I suspect some level of GC support will be needed in WASM for good performance
  - moonchild 6y ago
    I assume the GP was referring to wasm running on top of graal, not graal running on top of wasm. I don't think graal atop wasm would be a particularly interesting use case. Wasm purports to be a portable, secure, performant application runtime. Graal purports to be a portable, secure , performant application runtime. The latter, however, has had many more engineer-hours thrown at its implementation, and is thus both more heavyweight (so it needs all the resources it can get) and more performant (so it makes sense to use it as the backing runtime).
    - pawelmurias 6y ago
      Wasm is build as an efficient target for C/C++ like languages. It's mostly a striped down portable CPU intruction set. Graal/Truffle is intended to be an efficient target for everything. It's a toolbox of crazy magic for building your own JIT. There are not equivalent.
      - 6y ago

fniephaus 6y ago

Espresso's README.md contains some interesting details, for example: > ... it already passes >99.99% of the Java Compatibility Kit ... > Running HelloWorld on three nested layers of Espresso takes ~15 minutes. Link: https://github.com/oracle/graal/tree/6dd83cd94763b8736b42063f3cbf288b8add4128/espresso#espresso-coffee https://github.com/oracle/graal/tree/6dd83cd94763b8736b42063...

pulse7 6y ago
Regarding performance: "Note that current raw performance of Java on Truffle isn’t representative of what it will be capable of in the near future. The peak performance is several times lower than running the same code in the usual JIT mode. The warmup also hasn’t been optimized yet. We focused in this initial release entirely on the functionality, compatibility, and making Java on Truffle open source available for a broader community. ... Expect performance, both warmup and peak performance to increase rapidly in each of our upcoming 21.x releases."
JackFr 6y ago
> Running HelloWorld on three nested layers of Espresso takes ~15 minutes. It’s like how time works in “Inception”.

emmanueloga_ 6y ago

First thing, I think Graal/Truffle is really cool tech. Second thing... what's the story when it comes to Truffle licensing? :-) Would Oracle control the implementation of a particular language that used Truffle? Could they decide to "deplatform" that language? ("we don't authorize the use of Truffle in language implementation X for Y reasons") Or charge for licenses for users of that language? Or other somber scenarios... according to current licensing or in a hypothetical future ... Compare with, say, LLVM infrastructure, were it seems more certain that a language can be implemented as free software and with less restrictions or caveats.

suyash 6y ago
GraalVM is open source project
- nextaccountic 6y ago
  This didn't stop Oracle from suing Google about Java APIs.
  - johnnycerberus 6y ago
    Google deserved it. They took the APIs out from the commercial implementation.
  - jolux 6y ago
    Google wasn't copying from OpenJDK.
  - kaba0 6y ago
    Java wasn’t open-source at the time Google copied it. In fact, the only thing that was prohibited by Sun’s license was mobile usage - they wanted to make money on Java with it. So Google should get sued to hell for blatantly copying it (and they are really bad at shepharding, just look at the state of android java vs openjdk)
    - pwdisswordfish5 6y ago

deleted 6y ago

[deleted]

ivanb 6y ago

Java livecoding now doesn't look all that out of reach.

fniephaus 6y ago
I agree! Our work on TruffleSqueak [1] and on Polyglot Live Programming [2] has shown that it's possible to build language-agnostic live programming tools with GraalVM. If Espresso implements the required Truffle APIs correctly, our tools should also just work for Java. :) [1] https://github.com/hpi-swa/trufflesqueak/ https://github.com/hpi-swa/trufflesqueak/ [2] https://github.com/hpi-swa/polyglot-live-programming https://github.com/hpi-swa/polyglot-live-programming

pulse7 6y ago

This is cool for former Smalltalkers: "Advanced class redefinition" (there was previous attempt at http://dcevm.github.io/ http://dcevm.github.io/ to bring this to HotSpot, but Sun/Oracle decided not to increase HotSpot complexity - see https://openjdk.java.net/jeps/159 https://openjdk.java.net/jeps/159). So it seems JVM is one step closer to the Smalltalk VM...

brodo 6y ago
This kind of stuff used to work in Objective-C too, but it was removed step by step for performance reasons. If you allow it, for every call you do to such an object you have to first check if the method exits on it or somewhere up the inheritance chain. You can cache of course, but adding or removing a method to an object invalidates the cache for the object itself and everything that inherits from it's class.
- pulse7 6y ago
  In debugging mode it can work a bit slower and allow all this...
- drkrab 6y ago
  In a modern JIT with dynamic decompilation you can do these things in place, because the compiler essentially has global knowledge. The only real issue is to define the semantics (and then implement it of course). Objective-C is AOT compiled so the runtime checks are needed all the time.
- saagarjha 6y ago
  I'm not sure why you think it's been removed? The entire runtime is still there…the cache you're talking about still exists and is hit for every method call.
  - brodo 6y ago
    I wanted to do method swizzling in Objective C around 10 years ago. The methods for removing/replacing selectors where deprecated around that time.

pulse7 6y ago

How is Java on Truffle related to Substrate VM (https://www.graalvm.org/reference-manual/native-image/SubstrateVM/ https://www.graalvm.org/reference-manual/native-image/Substr...). Isn't Substrate VM also implemented in Java?

sradman 6y ago
Substrate is the key component that enables Ahead-of-Time compiled Native Images [1] on GraalVM. Java on Truffle enables bytecode to be dynamically loaded in a Native Image. Before Java on Truffle, you had to choose either pure compiled or pure dynamic. [1] https://www.graalvm.org/reference-manual/native-image/ https://www.graalvm.org/reference-manual/native-image/
- vips7L 6y ago
  Which is completely amazing considering how much dynamic and reflective code there is floating around in the Java ecosystem. I've never been able to compile anything beyond a trivial app with native-image because there is always something dynamic being used somewhere. I'm really looking forward to seeing where espresso goes.
  - kaba0 6y ago
    I think reflection works with GraalVM native compile - the only catch is that the set of classes to be inspected by it should be known beforehand.
    - pulse7 6y ago
      This means you can't load JARs at runtime with ClassLoader in GraalVM natively compiled image...
      - kaba0 6y ago
        Yes. But for longer running apps you are probably better off with a JVM since it will have better peak performance.

grashalm 6y ago

GraalVM dev here. Note that Java on Truffle is fully Open Source and available on Github. If you can read Java code and you are interested in how it is implemented start reading here: https://github.com/oracle/graal/blob/espresso/espresso/src/com.oracle.truffle.espresso/src/com/oracle/truffle/espresso/nodes/BytecodeNode.java#L634 https://github.com/oracle/graal/blob/espresso/espresso/src/c... If you are interested in a deep dive into the Truffle technology and are interested in why it makes sense to implement a language on top ofTruffle checkout my recent Rebase talk for a really long answer: https://youtu.be/O4icaN9khp4 https://youtu.be/O4icaN9khp4 If you don't have enough time for an 1h talk checkout my summary tweet: https://twitter.com/grashalm_/status/1212763944043139072 https://twitter.com/grashalm_/status/1212763944043139072

grashalm 6y ago
Also join us on Slack if you have questions: https://www.graalvm.org/slack-invitation/ https://www.graalvm.org/slack-invitation/
jarym 6y ago
Hey, I absolutely love Graal and where it is going. Big problem for me has been the license: GPLv2+CPE. On its own this is not a problem but coming from Oracle it makes people nervous. I think if there's ever room to move towards Apache 2 or similar license it would be really welcome.
- deleted 6y ago
  [deleted]
- pwdisswordfish5 6y ago
  There's no reason to think that you're safe even if it were Apache-licensed. One of the things that was made clear in Oracle v. Google is that Oracle effectively treats litigation as an essential expense for exploring all revenue sources, leaving others susceptible to suits whether they have merit or not. Compounding this latter concern was that another thing made clear is that the terms of the respective licenses is something that Oracle doesn't consider important. Refer to McNealy testifying for example that commercial use of even GPL-licensed work is prohibited (despite the terms of the license not supporting this stance).

geokon 6y ago

I'm not super familiar with the ecosystem, but does the GraalVM compiler provide a way to "tree shake" dependencies? This past year I wrote a rather simple desktop app (JavaFX) for work using Clojure. But Java by default uses RTTI - and Clojure by extension does as well - the dependency tree would balloon my final executable. For instance, I'd bring in some CV library like BoofCV to do some very basic image manipulation, but all of BoofCV and its dependencies would get dragged in. Hundreds of megabytes of junk.. So you either have to just accept you have a gargantuan executable or you have to use some smaller subpar libraries to do what you want. But it seems unfortunate the ecosystem pushes you to use less/smaller dependencies instead of using robust large ones. I understand the reason behind it. The java compiler has no way to ensure which classes will be used and which won't be b/c crazy things can happen at run time. Maybe with all the work on GraalVM people will move their libraries to not use RTTI as much? I haven't had a chance to hook up Graal yet (I think it doesn't play nice with JavaFX.. or maybe that's old news) - but it's unclear if it'll slim down the final binary. If it does - then this potentially a game changer for "deliverable" executables :) PS: You can manually go in and disable sub-dependencies.. but it's ugly and incomplete. I got Clojure/JFX/Java to compile down to something like 60MB - but my app is simple and it really should be more like 2MB.

chrisseaton 6y ago
> I'm not super familiar with the ecosystem, but does the GraalVM compiler provide a way to "tree shake" dependencies? Yes it does whole-world analysis and only compiles in classes, methods, and fields, which are actually used. The executables do have a minimum size, because the GC code for example doesn't get any smaller, but I think 2 MB is around the area of what can be achieved, yes.
Chris2048 6y ago
Is there more terminology that means "to tree-shake"? I understand javascript does tree-shaking, mainly in the context of code-minifiers, and certain languages do "path optimisation" usually at runtime - but I'm not sure how to describe the removal, and modification[0] of code (say, interpreted code) outside JS. I'd like to "tree-shake" python in order to see what % of code in it's deps is actually used. [0] e.g removing static parameters, replacing fns with lots of cases into multiple fns etc.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

ksec 6y ago

So someday I will be able to Run the whole Stack, Java ( Elasticsearch ), Ruby ( Rails ) , Javascript, and C all on top of GraalVM?

foolinaround 6y ago

What are some immediate (and also long term) practical applications of this advancement?

mukel 6y ago
The goal is not to compete, but rather complement HotSpot/GraalVM with: - (Polyglot) scripting with Java - Augmenting native images e.g. native javac with instant startup + annotation processors (very dynamic) running on Espresso - A simple non-invasive JVM for constrained environments - DCEVM-like features for developers - Approachable academic playground - Fast prototyping of JVM features e.g. it took our intern just two weeks to implement invokedynamic/MethodHandles

StephanRauh 6y ago

I wonder which use cases Espresso has. Until now, it looks like a very tech-focus project. That's fine, no doubt about that. But I guess there are business use-cases, too. Any ideas?