Java on Truffle – Going Fully Metacircular(medium.com)
medium.com
Java on Truffle – Going Fully Metacircular
https://medium.com/graalvm/java-on-truffle-going-fully-metacircular-215531e3f840
168 comments
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.
I think if there's ever room to move towards Apache 2 or similar license it would be really welcome.
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).
And there is no reason the spread FUD.
Oracle v. Google has nothing to do with it (Java’s licence at the time explicitly disallowed mobile usage) Do you have an examples that give rise to any sort of concern about the usage of GPL-licenced code (regardless of code owner)?
Oracle v. Google has nothing to do with it (Java’s licence at the time explicitly disallowed mobile usage) Do you have an examples that give rise to any sort of concern about the usage of GPL-licenced code (regardless of code owner)?
It's like we're not even having the same conversation. McNealy, founder of Sun, testified under oath that GPL doesn't permit commercial use. What was unclear about this the first time it was stated?
> GPL doesn't permit commercial use
That is alarmingly false. Do you have a source that McNealy indeed has said that? I couldn't find anything by googling.
That is alarmingly false. Do you have a source that McNealy indeed has said that? I couldn't find anything by googling.
Scott McNealy, under direct examination on 2012 April 26: "you can't license GPL code and then resell it for a profit"
Source: Official Reporters for the US District Court for the Northern District of California (regarding Oracle v. Google, 3:10-cv-03561)
Source: Official Reporters for the US District Court for the Northern District of California (regarding Oracle v. Google, 3:10-cv-03561)
[deleted]
Question for you, but first I just want to say thanks! The technology is awesome.
That Tetris game is that a command line thing? If so what library are you using to manipulate the console? I've wanted to create interactive command line utilities with the JVM for a long time and it's always been not supported.
That Tetris game is that a command line thing? If so what library are you using to manipulate the console? I've wanted to create interactive command line utilities with the JVM for a long time and it's always been not supported.
It's a Linux-only trick: https://github.com/kt97679/tetris/blob/52dfb3a703e4dd5b37990...
Ok what on earth is going on there... It's launching a shell but I'm not sure what the stty does
that's this tetris: https://github.com/kt97679/tetris/blob/master/Tetris.java
ncurses I think. There's an issue with how jconsole and tetris work together, so when tetris exits, jshell does too.
ncurses I think. There's an issue with how jconsole and tetris work together, so when tetris exits, jshell does too.
Also join us on Slack if you have questions:
https://www.graalvm.org/slack-invitation/
> A new compiler or GC optimisation often requires years of work. With GraalVM that work does not need to be replicated for every language.
Isn't this only true for GCC code that operates above the GENERIC form level?
Isn't this only true for GCC code that operates above the GENERIC form level?
Not sure what you're saying here.
The ‘GC’ refers to garbage collector, not GCC.
It is true that you can write a compiler frontend targeting a generic backend (like GCC), and take advantage of existing optimizations. Truffle's somewhat unique value prop is that you can write a basic interpreter (not compiler) and get performance approaching that of a top-end JIT.
The ‘GC’ refers to garbage collector, not GCC.
It is true that you can write a compiler frontend targeting a generic backend (like GCC), and take advantage of existing optimizations. Truffle's somewhat unique value prop is that you can write a basic interpreter (not compiler) and get performance approaching that of a top-end JIT.
Any chance of a wasm and/or llvm backends?
A question: how does a company allegedly so lawyer-first, tech-second manage to develop such cutting edge software? Oracle isn't normally a name that comes to mind when people think of programming language research.
> Oracle isn't normally a name that comes to mind when people think of programming language research.
Oracle has a very large, well-funded, and long-term PL research lab that consistently produces top-tier papers, and funds and collaborates with many academics.
If it doesn't come to mind when thinking about PL research then I can't think you're reading much PL research.
Oracle has a very large, well-funded, and long-term PL research lab that consistently produces top-tier papers, and funds and collaborates with many academics.
If it doesn't come to mind when thinking about PL research then I can't think you're reading much PL research.
GraalVM was born in Oracle Labs, the spiritual successor of Sun Labs. There are many great innovations coming from Oracle Labs: https://labs.oracle.com/pls/apex/f?p=94065:INTRO::::::
>so lawyer-first, tech-second manage to develop such cutting edge software?
Most DBA I met would not argue against Oracle having the best Database. Whether they would choose to use it for their projects is entirely different though. Something that is objectively good has zero to do with whether you like or dislike the company.
The amount of work that is going into JVM and VM research is absolutely insane. One VM to Rule them All, [1], that was submitted to HN in 2013.
[1] https://news.ycombinator.com/item?id=6232240
Most DBA I met would not argue against Oracle having the best Database. Whether they would choose to use it for their projects is entirely different though. Something that is objectively good has zero to do with whether you like or dislike the company.
The amount of work that is going into JVM and VM research is absolutely insane. One VM to Rule them All, [1], that was submitted to HN in 2013.
[1] https://news.ycombinator.com/item?id=6232240
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.
And for what it’s worth, TruffleRuby on Truffle/GraalVM (reportedly derived from JRuby) is supposed to be incredibly fast.
Plenty of languages (commercially) target the CLR, however given its Windows focus, many UNIX FOSS based researchers never cared about it, even in the presence of mono.
I don’t know of a modern Ruby, Python, or JavaScript environment for the CLR.
Microsoft abandoned IronRuby and IronPython around 10 years ago. Meanwhile TruffleRuby on GraalVM is the fastest Ruby implementation by far.
Microsoft abandoned IronRuby and IronPython around 10 years ago. Meanwhile TruffleRuby on GraalVM is the fastest Ruby implementation by far.
There are other languages out there.
From Microsoft itself, F**, F#, VB.NET, C#, Sing#, System C#, Managed C++, C++/CLI, Cω, Axum, and who knows what else they have done internally.
From Microsoft partners, COBOL, Eiffel, Ada, Fortran.
From FOSS community and university researchers, not so much because it is M$ and better not use Mono because of patents, so was the saying.
From Microsoft itself, F**, F#, VB.NET, C#, Sing#, System C#, Managed C++, C++/CLI, Cω, Axum, and who knows what else they have done internally.
From Microsoft partners, COBOL, Eiffel, Ada, Fortran.
From FOSS community and university researchers, not so much because it is M$ and better not use Mono because of patents, so was the saying.
Right -- but all of those languages are compilable to bytecode without a performance hit from lack of dynamic invocation at call sites.
That means the DLR is effectively dead, I think -- along with all languages for which the CLR's static call sites mean slowed performance.
That means the DLR is effectively dead, I think -- along with all languages for which the CLR's static call sites mean slowed performance.
So now the point isn't that many languages are supported, rather which ones make use of dynamic and dispatch interfaces?
I’m talking about dynamic dispatch and the languages that depend on it for performance.
The CLR has been cross-platform as CoreCLR since 2016.
Indeed, and here I am targeting .NET Framework 4.7.2, because the ecosystem isn't fully compatible with Core.
Plus on UNIX, Java has 25 years of history, not 4 (not counting WIP mono here).
Plus on UNIX, Java has 25 years of history, not 4 (not counting WIP mono here).
I'm well aware :) just wanted to clarify since this comes up a lot.
I spent most of last year maintaining a Web Forms app. It's no fun. Ironically, there used to be many more CLR languages, because Microsoft paid for their development. IronPython and IronRuby stand out. I wish ClojureCLR weren't dead too.
I spent most of last year maintaining a Web Forms app. It's no fun. Ironically, there used to be many more CLR languages, because Microsoft paid for their development. IronPython and IronRuby stand out. I wish ClojureCLR weren't dead too.
> I wish ClojureCLR weren't dead too.
A google search would tell you otherwise.
https://groups.google.com/g/clojure-clr/c/2v9xls5hreE
Last commit 6 days ago: Last code change 11 days ago: https://github.com/clojure/clojure-clr/commits/master
A google search would tell you otherwise.
https://groups.google.com/g/clojure-clr/c/2v9xls5hreE
Last commit 6 days ago: Last code change 11 days ago: https://github.com/clojure/clojure-clr/commits/master
I stand corrected. I assumed that the low velocity was a sign it was flagging.
> I wish ClojureCLR weren't dead too
Is there any reason for saying that? Checking the commits history on Github[1], the project seems still alive.
[1]https://github.com/clojure/clojure-clr/commits/master
Is there any reason for saying that? Checking the commits history on Github[1], the project seems still alive.
[1]https://github.com/clojure/clojure-clr/commits/master
I don't have a huge amount of insight into the project but the commits over time don't look super healthy: https://github.com/clojure/clojure-clr/graphs/commit-activit...
Either way it's pretty clearly not a core platform for Clojure.
Either way it's pretty clearly not a core platform for Clojure.
Using your yardstick, ClojureCLR might look like the primary platform if you compare to Clojure proper: https://github.com/clojure/clojure/graphs/commit-activity
As I wrote below, I misjudged the project because of the low activity in its issues. Clearly the projects are not managed through GitHub, which is what I am used to. I made a mistake.
I could see GraalVM being a part of whatever replaces Docker.
Most of the stuff people use Docker for, I was already doing in 2006 with WebSphere and EAR "images".
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.
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.
Absolutely. It was hellish. Very few people understood how intricate this was, how bad the logging/messages were when you got it wrong, and paid little or no mind to being able to be portable between application server implementations from the word go.
Just to be clear, I was talking about J2EE deployments of the time in general, not WebSphere in particular. I was mainly stuck on JBOSS 2.x/3.x and I was keen on using Resin instead.
Yuck.
Yuck.
Without regard to the merit of each tech, I've made the J2EE to K8S comparison before and am glad to see here I am not the only one who saw the resemblance.
It mostly goes to show that containerizing application code for execution in a managed environment in nothing new. I'm sure this was also done somehow in the mainframe world.
As to whether K8S is a superior embodiment of the concept, I'd say that the problem is rather that a large majority of adopters are just cargo-culting without having a real need for what it actually provides, externalizing the costs of complexity it brings. I have nothing against K8S itself, but its adoption curve is telling of CV-driven architecture at it's worst. Mind you, the same might have been said of J2EE back in the day.
It mostly goes to show that containerizing application code for execution in a managed environment in nothing new. I'm sure this was also done somehow in the mainframe world.
As to whether K8S is a superior embodiment of the concept, I'd say that the problem is rather that a large majority of adopters are just cargo-culting without having a real need for what it actually provides, externalizing the costs of complexity it brings. I have nothing against K8S itself, but its adoption curve is telling of CV-driven architecture at it's worst. Mind you, the same might have been said of J2EE back in the day.
> I'm sure this was also done somehow in the mainframe world.
LPAR -- https://en.wikipedia.org/wiki/Logical_partition
Upon understanding this, I realised that there is / was nothing new under the sun.
LPAR -- https://en.wikipedia.org/wiki/Logical_partition
Upon understanding this, I realised that there is / was nothing new under the sun.
Even safe systems programming languages, with unsafe code blocks.
https://en.wikipedia.org/wiki/Burroughs_large_systems
https://en.wikipedia.org/wiki/NEWP
If you follow NEWP manual from Unisys (nowadays still selling Burroughs as ClearPath), you will see UNSAFE code blocks and how its use tainted binaries, which requires admin permission for execution.
https://en.wikipedia.org/wiki/Burroughs_large_systems
https://en.wikipedia.org/wiki/NEWP
If you follow NEWP manual from Unisys (nowadays still selling Burroughs as ClearPath), you will see UNSAFE code blocks and how its use tainted binaries, which requires admin permission for execution.
> It mostly goes to show that containerizing application code for execution in a managed environment in nothing new. I'm sure this was also done somehow in the mainframe world.
Yes, it's called an operating system :-)
Yes, it's called an operating system :-)
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.
That java -jar usually requires a clusterfuck of dependencies and configuration.
Exactly! Sometime WS would fail to start a local instance in IDE in 5 minutes and timeout. It was hilariously bad software.
I did not have any problems getting WAS to run locallly and I was very Java newbie at that time. I guess I was just lucky. It was literally the first thing I did on my first Java work: I installed WAS and started writing some servlets.
For just getting something simple/singular up and running it was passable.
The problem was when it was used for multiple services (as his comparison with EAR and docker implies). Lets say you had a service for something packaged as EAR. You would then have to log in to the dashboard, add the package and configure it manually. If something changed with the package, you would probably have to reinstall it in WAS, you couldn't just pull the newest from git in your repo and be done. And if that needed any config changes, everyone on the team had to do the same locally and manually in the control panel. When you got multiple moving parts, you would spend more time bringing them in and configuring everything correctly than actually developing whatever you were supposed to.
But what I wasted most time on was certificates. Everything had to be signed and stuff, mostly self signed by randoms and more theater than security. Sooo many times stopped working because the certificate for some module expired, or the CAS was unknown and had to be manually loaded into everyone's local install etc.
The problem was when it was used for multiple services (as his comparison with EAR and docker implies). Lets say you had a service for something packaged as EAR. You would then have to log in to the dashboard, add the package and configure it manually. If something changed with the package, you would probably have to reinstall it in WAS, you couldn't just pull the newest from git in your repo and be done. And if that needed any config changes, everyone on the team had to do the same locally and manually in the control panel. When you got multiple moving parts, you would spend more time bringing them in and configuring everything correctly than actually developing whatever you were supposed to.
But what I wasted most time on was certificates. Everything had to be signed and stuff, mostly self signed by randoms and more theater than security. Sooo many times stopped working because the certificate for some module expired, or the CAS was unknown and had to be manually loaded into everyone's local install etc.
The story with certificates is still quite up-to-date with docker, k8s and other stuff nowadays.
Just last December I was having similar fun with certificates and "modern" approaches.
Just last December I was having similar fun with certificates and "modern" approaches.
Sorry but I will take Websphere over Docker/Kubernetes any day of the week.
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/6dd83cd94763b8736b42063...
> ... 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/6dd83cd94763b8736b42063...
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."
> Running HelloWorld on three nested layers of Espresso takes ~15 minutes.
It’s like how time works in “Inception”.
It’s like how time works in “Inception”.
I'm still impressed by the amount of crazy-impressive tooling the Java ecosystem has compared to other languages.
correction:
> other mainstream languages
> other mainstream languages
Are there non-mainstream languages with more tooling? Seems like it would be a bit surprising if there were…
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.
And indeed, there are a couple of things that Java and .NET still don't do.
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
They did, some of them went to work on V8 and Dart 1.0 VM afterwards.
I’m more impressed that they still think XML is great for project configuration .
Who cares what it's written in? While I find lots of XML configs often to be verbose, translating it to JSON would be exactly the same mess. It's often what has to be configured that's the problem, and not how or the syntax of it.
If anything, XML with schema works out of the box in most IDEs with autocomplete, validation etc.,
If anything, XML with schema works out of the box in most IDEs with autocomplete, validation etc.,
Oh, I hate xml as a config language. But at least it has support for comments - unlike json (hacks not withstanding).
Thinking out loud...
The problem with XML is mostly syntactical: it's not always clear if something should be a node or an attribute, and it doesn't have actual lists, maps, or scalar types.
JSON has more structural issues: it can be too terse, so if you're not careful with naming fields, it can be really hard to tell what type of object something is, and for polymorphic lists, you're out of luck.
The problem with XML is mostly syntactical: it's not always clear if something should be a node or an attribute, and it doesn't have actual lists, maps, or scalar types.
JSON has more structural issues: it can be too terse, so if you're not careful with naming fields, it can be really hard to tell what type of object something is, and for polymorphic lists, you're out of luck.
And I'm impressed that JSON still does not have an official, standards-body-sanctionned Schema specification. Nor does it have a thousand other little things that make XML still so solid when coding for the future.
Schema validation, proper types, comments, IDE completion support, and no significant white spaces, just what I ordered.
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.
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.
> 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.
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.
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.
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.
> Is there more terminology that means "to tree-shake"?
Yes, everyone else calls this dead code elimination. [1]
(the custom term isn't completely unreasonable, since tree shaking is somewhat different from how compilers do DCE)
https://en.wikipedia.org/wiki/Dead_code_elimination
Yes, everyone else calls this dead code elimination. [1]
(the custom term isn't completely unreasonable, since tree shaking is somewhat different from how compilers do DCE)
https://en.wikipedia.org/wiki/Dead_code_elimination
Ah okay. To me "tree shaking" was implicitly talking about the dependency tree and removing unused library dependencies. While "dead code elimination" would be a "deep" clean done by a linker when making a static binary (mostly C/C++ land..). There you're looking at a finer granularity than libraries/compilation-units. That's necessarily a bit trickier and I wasn't even thinking that far. But it seems the GraalVM compiler work on this level.
That page describes "dynamic" elimination, but let's say I call sqrt(x) in my module, but for a fixed value of x - in that case I can just replace the whole fn with a fixed value, but it would require me to detect that the fn is deterministic. Would that still count?
This is cool for former Smalltalkers: "Advanced class redefinition" (there was previous attempt at 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). So it seems JVM is one step closer to the Smalltalk VM...
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.
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.
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.
I wanted to do method swizzling in Objective C around 10 years ago. The methods for removing/replacing selectors where deprecated around that time.
They are not deprecated: https://developer.apple.com/documentation/objectivec/objecti....
In debugging mode it can work a bit slower and allow all this...
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.
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.
This seems like FUD. Truffle is licensed under the permissive UPL[0]. Even if they decided to make newer versions of it closed-source the opensource versions would still be available, and their licenses would continue to hold.
This happened with solaris: oracle decided to make new ‘official’ development closed, but the last opensource version continued to be used and developed by the community.
0. https://github.com/oracle/graal/blob/master/truffle/LICENSE....
This happened with solaris: oracle decided to make new ‘official’ development closed, but the last opensource version continued to be used and developed by the community.
0. https://github.com/oracle/graal/blob/master/truffle/LICENSE....
"FUD" is a concerted effort to outsell a competitor or something like that... I'm just an individual with real questions about implications of the licenses involved. I bet others have similar questions.
Graal licensing seems pretty complicated to me, and if I get it right Truffle only makes sense when used together with Graal.
From what I could find in the FAQ [1]:
* "GraalVM Community is free to use for any purpose and comes with no strings attached, but also no guarantees or support."
* "GraalVM Enterprise includes Improved performance and security over GraalVM Community"
In general it seems pretty good, but I think it is a bit painful to have to pay for certain optimizations... again, imagine if projects had to pay to, say, "clang -O3". Also could be painful to get stuck in Graal/Truffle version N if version N+1 switches to different licensing terms.
In general commercial compilers are a bit of a drag to work with... I use Saxon from time to time and sometimes I need to check the matrix to see if a feature is available or not [2]. For instance, until version 10.0, higher order functions (!) was a feature one had to pay for, for whatever reason.
--
1: https://www.graalvm.org/faq/#how-is-graalvm-licensed
2: https://www.saxonica.com/products/feature-matrix-10.xml
Graal licensing seems pretty complicated to me, and if I get it right Truffle only makes sense when used together with Graal.
From what I could find in the FAQ [1]:
* "GraalVM Community is free to use for any purpose and comes with no strings attached, but also no guarantees or support."
* "GraalVM Enterprise includes Improved performance and security over GraalVM Community"
In general it seems pretty good, but I think it is a bit painful to have to pay for certain optimizations... again, imagine if projects had to pay to, say, "clang -O3". Also could be painful to get stuck in Graal/Truffle version N if version N+1 switches to different licensing terms.
In general commercial compilers are a bit of a drag to work with... I use Saxon from time to time and sometimes I need to check the matrix to see if a feature is available or not [2]. For instance, until version 10.0, higher order functions (!) was a feature one had to pay for, for whatever reason.
--
1: https://www.graalvm.org/faq/#how-is-graalvm-licensed
2: https://www.saxonica.com/products/feature-matrix-10.xml
As far as I know, full, profile-guided optimizations are the only paid features. Also, if Graal is instead used in place of Hotspot as a JIT compiler, there is no need for that so you get the “whole package”.
Sadly, a significant number of performance/sandboxing/debugging features is only available in EE. Also holds for JIT (at least wrt. performance).
Which is why you can enjoy all the LLVM features used by Apple, Sony and Nintendo. /s
GraalVM is open source project
This didn't stop Oracle from suing Google about Java APIs.
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)
This comment is playing fast and loose with the facts. No part of Oracle's suit against Google relied on the claim that "Java wasn't open-source at the time Google copied it" (for good reason).
> they are really bad at shepharding, just look at the state of android java vs openjdk
This has nothing to do with copyright law―the thing that Google was sued for. There is no legal argument in this remark (which is the problem with about half the comments that appear saying that Google was in the wrong), just an assertion based on an appeal to emotion that Google deserved to be sued, and then working backwards from there to present a half-formed argument.
> they are really bad at shepharding, just look at the state of android java vs openjdk
This has nothing to do with copyright law―the thing that Google was sued for. There is no legal argument in this remark (which is the problem with about half the comments that appear saying that Google was in the wrong), just an assertion based on an appeal to emotion that Google deserved to be sued, and then working backwards from there to present a half-formed argument.
> No part of Oracle's suit against Google relied on the claim that "Java wasn't open-source at the time Google copied it"
It had a specific license explicitly disallowing mobile use. Everything else is irrelevant - google knowingly broke the license, didn’t they? This is copyright infringement. As for whether their copy of Java’s API at the time could constitute fair use and thus not subject to copyright law is up to debate and my personal opinion doesn’t matter on it.
It had a specific license explicitly disallowing mobile use. Everything else is irrelevant - google knowingly broke the license, didn’t they? This is copyright infringement. As for whether their copy of Java’s API at the time could constitute fair use and thus not subject to copyright law is up to debate and my personal opinion doesn’t matter on it.
> It had a specific license explicitly disallowing mobile use. Everything else is irrelevant...
The Java Specification explicitly allows people to re-implement the Java Language as long as they follow a few guidelines (which google allegedly did not, hence the lawsuit) -- even if they decide to target a mobile platform.
The Java Specification explicitly allows people to re-implement the Java Language as long as they follow a few guidelines (which google allegedly did not, hence the lawsuit) -- even if they decide to target a mobile platform.
This is a perplexing response. Oracle's case against Google is about copyright infringement. On that point, you are correct, but that's where your comments part from reality.
Oracle in its case against Google is not arguing that "Java wasn't open-source at the time Google copied it". Oracle in its case against Google is not arguing that there was "a specific license explicitly disallowing mobile use". You on the other hand are arguing these things. That's where the problem lies: you're asserting infringement based on two fact claims that don't even match what Oracle's legal team presented to the courts.
(For that reason, your remark that "Everything else is irrelevant" is just bizarre and ironic—it's your comments here that are irrelevant... _None_ of the things you're saying are what the case is actually about.)
Here are some simple questions: to what extent does your knowledge of Oracle v. Google originate from secondary analysis and commentary about the case vs. direct knowledge (e.g. the briefs and testimony provided by Oracle and those who testified)? Do you have any firsthand experience reviewing the material that was presented in/to the courts? This is the problem with Internet peanut galleries. The answer to the last question can be solid "no", and yet commenters are undeterred from spewing nonsense from their gut that has no basis in reality.
Oracle in its case against Google is not arguing that "Java wasn't open-source at the time Google copied it". Oracle in its case against Google is not arguing that there was "a specific license explicitly disallowing mobile use". You on the other hand are arguing these things. That's where the problem lies: you're asserting infringement based on two fact claims that don't even match what Oracle's legal team presented to the courts.
(For that reason, your remark that "Everything else is irrelevant" is just bizarre and ironic—it's your comments here that are irrelevant... _None_ of the things you're saying are what the case is actually about.)
Here are some simple questions: to what extent does your knowledge of Oracle v. Google originate from secondary analysis and commentary about the case vs. direct knowledge (e.g. the briefs and testimony provided by Oracle and those who testified)? Do you have any firsthand experience reviewing the material that was presented in/to the courts? This is the problem with Internet peanut galleries. The answer to the last question can be solid "no", and yet commenters are undeterred from spewing nonsense from their gut that has no basis in reality.
About your last paragraph, I did try to get as close to primary sources as possible, without digging into the actual briefs, and I am no lawyer, so my understanding on these topics have a shaky foundation.
But if you have done so, at least you as a presumably secondhand information source, could you give me a rebuttal on why am I wrong?
But if you have done so, at least you as a presumably secondhand information source, could you give me a rebuttal on why am I wrong?
Just like your last message[1], the answer is "but why male models?" (in other words, I just answered that[2]; do you want me to repeat it[3] or something?)
1. https://news.ycombinator.com/item?id=25847574
2. https://news.ycombinator.com/item?id=25846415
3. https://news.ycombinator.com/item?id=25848980
1. https://news.ycombinator.com/item?id=25847574
2. https://news.ycombinator.com/item?id=25846415
3. https://news.ycombinator.com/item?id=25848980
Google wasn't copying from OpenJDK.
Google could have bought Sun, decided not to take the opportunity.
They also made a clusterfuck job copying Java APIs for their Android Java (aka Google's J++) dialect, where Java library authors have to hunt down what works exactly in each Android version.
They have only themselves to blame.
They also made a clusterfuck job copying Java APIs for their Android Java (aka Google's J++) dialect, where Java library authors have to hunt down what works exactly in each Android version.
They have only themselves to blame.
Google deserved it. They took the APIs out from the commercial implementation.
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-imple... to disambiguate vs the probably better known smart contract development framework with the same name.
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/
1: https://www.trufflesuite.com/
Yeah, I’ve known about Graal/Truffle for years, and just heard about the smart contract thing today.
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.
[deleted]
not sure why you were downvoted. I instantly thought of Truffle as it relates to smart contract work as well
same.
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?
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-f...
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-f...
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.
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.
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.
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.
> Java on Truffle is a normal Java application, it can run on a vanilla OpenJDK, doesn't need the bootstrap step.
Okay, but if you're not bootstrapping, then you still need to keep OpenJDK around, and you're still hugely dependent upon big chunks of C++ code in OpenJDK, particularly in the garbage collector, unless they've added a crazy in-memory bootstrapping hook to OpenJDK to switch garbage collectors without shutting down the JVM.
Maybe there are some rapid development advantages to not requiring bootstrapping, but that means huge amounts of complexity around allowing re-definition of classes at runtime, particularly key JVM internals. Changing a tire without stopping the car is going to be very tricky.
Okay, but if you're not bootstrapping, then you still need to keep OpenJDK around, and you're still hugely dependent upon big chunks of C++ code in OpenJDK, particularly in the garbage collector, unless they've added a crazy in-memory bootstrapping hook to OpenJDK to switch garbage collectors without shutting down the JVM.
Maybe there are some rapid development advantages to not requiring bootstrapping, but that means huge amounts of complexity around allowing re-definition of classes at runtime, particularly key JVM internals. Changing a tire without stopping the car is going to be very tricky.
Pypy implements Futamura projections too.
How is Java on Truffle related to Substrate VM (https://www.graalvm.org/reference-manual/native-image/Substr...). Isn't Substrate VM also implemented in Java?
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/
[1] https://www.graalvm.org/reference-manual/native-image/
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.
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.
Yes but it's extremely difficult to know them before hand. Trust me I've tried. It's not a trivial thing to do. The only success I've had is with quarkus [0] and thats only if you don't go outside of what the framework provides.
[0] https://quarkus.io/
[0] https://quarkus.io/
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?
So someday I will be able to Run the whole Stack, Java ( Elasticsearch ), Ruby ( Rails ) , Javascript, and C all on top of GraalVM?
What are some immediate (and also long term) practical applications of this advancement?
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
- (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
Java livecoding now doesn't look all that out of reach.
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/ [2] https://github.com/hpi-swa/polyglot-live-programming
[1] https://github.com/hpi-swa/trufflesqueak/ [2] https://github.com/hpi-swa/polyglot-live-programming
[deleted]
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.
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.
There's already GraalVM Wasm: https://www.graalvm.org/reference-manual/wasm/
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
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).
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).
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.
Indeed, WASM will probably be a niche compared to what GraalVM offers.
But because of harmful politics graalvm isn't going to be included in browsers anytime soon
What if somebody will build a GraalVM-based browser? That would be something. Anyway, W3C recommends WebAssembly but does not impose it. It is not too late in the game because WASM doesn't even have DOM access, yet. And also people are still using browsers that are not WASM-ready. How many people actually compile their libraries to WASM today? Aside to early adopters scattered around Rust and Emscripten.
I don't see which actor in the industry (outside of browser makers) has the human resources to make such an experiment.
Mozilla were the one lobbying for wasm... and chromium has abandoned pnacl because of them. The only hope might be microsoft.
Oracle could do it in theory but I don't expect them to do it anytime soon.
There's TeaVM[0], which is an old project that compiles JVM bytecode to JS, and more recently, also to WASM.
I had thought the project had been abandoned, but I was wrong, it seems to be actively maintained and evolving on GitHub[1].
[0] http://teavm.org [1] https://github.com/konsoletyper/teavm/issues
I had thought the project had been abandoned, but I was wrong, it seems to be actively maintained and evolving on GitHub[1].
[0] http://teavm.org [1] https://github.com/konsoletyper/teavm/issues
GraalVM can output LLVM, which can go to WASM. In the past it also used to be able to output JavaScript. It should be easy enough to make it output WASM directly.
The GC is written in Java, so if you have the translation to WASM that's covered as well.
The GC is written in Java, so if you have the translation to WASM that's covered as well.
You can try to check for yourself with CheerpJ compiler.
https://www.leaningtech.com/pages/cheerpj.html
https://www.leaningtech.com/pages/cheerpj.html
You can already run Java on WebAssembly, if that is what you are after, Java Applets are back.
https://www.leaningtech.com/pages/cheerpj.html
https://www.leaningtech.com/pages/cheerpj.html
From a cursory look, jvm byte code and wasm byte code seem quite similar. where is the major mismatch btw underlying machine abstractions?
JVM has first class objects, exceptions and managed memory. WASM doesn't. This does not make one better than the other, just indicates their intended uses.
There are proposals currently in progress to add GC and exceptions to wasm.
As for objects, it's not clear to me how important it is to have runtime support for those.
As for objects, it's not clear to me how important it is to have runtime support for those.
Wasm is just a low quality jvm with lower human resources
It is basically just a portable cpu architecture with everything it entails (manual memory management, etc). While there are plans for a gc, it seems hard to fit into this model (but I’m sure the team can pull it off).
It is basically made so c/cpp and other low level languages could be run inside browsers, and I don’t really see the point of it? Like, it is probably good for a video editor running inside a browser, but it will probably mostly entail all sort of mining, unnecessarily usage of cpu and the like. And it won’t magically improve performance, since at the boundary , calling javascript is really expensive, usually much more than writing the whole thing in js. Unless of course if someone does plenty of numerical computations.
It is basically made so c/cpp and other low level languages could be run inside browsers, and I don’t really see the point of it? Like, it is probably good for a video editor running inside a browser, but it will probably mostly entail all sort of mining, unnecessarily usage of cpu and the like. And it won’t magically improve performance, since at the boundary , calling javascript is really expensive, usually much more than writing the whole thing in js. Unless of course if someone does plenty of numerical computations.
Politics.
Here is Flash doing the same with CrossBridge toolchain in 2011 with Unreal 3 citadel demo
https://adobe-flash.github.io/crossbridge/
https://www.youtube.com/watch?v=UQiUP2Hd60Y
Then there was PNaCl, but it wasn't good enough hence asmjs, and then WebAssembly, which is supposed to be secure.
Well,
"Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly"
https://www.youtube.com/watch?v=glL__xjviro
TedDRA ANDF, IBM i, z/OS, CLR and BREW are all examples of bytecodes that support C and C++.
Here is Flash doing the same with CrossBridge toolchain in 2011 with Unreal 3 citadel demo
https://adobe-flash.github.io/crossbridge/
https://www.youtube.com/watch?v=UQiUP2Hd60Y
Then there was PNaCl, but it wasn't good enough hence asmjs, and then WebAssembly, which is supposed to be secure.
Well,
"Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly"
https://www.youtube.com/watch?v=glL__xjviro
TedDRA ANDF, IBM i, z/OS, CLR and BREW are all examples of bytecodes that support C and C++.
Yes, I absolutely dislike the direction web browsers went - was just trying to illustrate the point of wasm.
In a more ideal world, I would like to see the JVM underneath modern web browsers
In a more ideal world, I would like to see the JVM underneath modern web browsers
Could you be more specific? What's lower quality?
Not lower quality per se but the feature set is order of magnitude smaller and thus is a missfeat for modern languages
It's just a different abstraction level.
Taking the argument to the extreme, assembly is a misfit.
Taking the argument to the extreme, assembly is a misfit.
X86 assembly/native code offers more features than wasm but is not portable or safe to execute.
Webasm is less powerful then graalvm/truffle.
although running a jvm inside of a jvm sounds fun, wouldn't this slow down an already slow interpreted application?
It's dynamically compiled to machine code - it's not 'interpreted' as you are probably thinking of it.
For example there is also a Truffle implementation of C running on the JVM that runs some benchmarks faster than native C (due to runtime optimisations being better than static optimisations.)
For example there is also a Truffle implementation of C running on the JVM that runs some benchmarks faster than native C (due to runtime optimisations being better than static optimisations.)
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.
Yes, but modern Java isn't really interpreted.
“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.
I get what you are trying to say but if (!) you use JVM you are using an interpreter.
According to this definition, C is an interpreted language because "there is" CINT. [1]
[1] https://web.archive.org/web/20190911160010/http://www.hanno....
[1] https://web.archive.org/web/20190911160010/http://www.hanno....
Wikipedias definition. And yes indeed!
> 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.
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.
[deleted]
[deleted]
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.
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.
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.
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.
If you're comparing Android with Graal, you don't understand what Graal is all about.
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.
Android’s java is pretty terrible in comparison, just saying.
[deleted]
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/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
If you don't have enough time for an 1h talk checkout my summary tweet: https://twitter.com/grashalm_/status/1212763944043139072