Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraalVM: Run Programs Faster Anywhere

graalvm.org

Post reply on HN
Print view View original

131–140 of 218 posts

Re: GraalVM: Run Programs Faster Anywhere

#131

Post by sametmax »

pjmlp wrote: post #121
oneplane wrote: post #56

Keep in mind that while this is nice technology, it's Oracle-based, split in CE/EE (which in itself is not a problem, but CE doesn't run on macOS), and they will find a way to screw you over at some point in the future regardless of what you do, use or choose.

Like Google, Microsoft, Apple dropping tech, or replacing it with something else, just because. Oracle has done lots of nice things for Java, some of them with uncertain future or even tabu at Sun, like Graal's percusor MaximeVM or AOT compilation. It might not be a company loved by FOSS, but other than IBM there wasn't anyone else caring that much for Java's fate, Google specially did not even bothered. So I appreci…

Your point being ?

We are all aware of the danger of using techs from those companies.

Re: GraalVM: Run Programs Faster Anywhere

#133

Post by truth_seeker »

grashalm wrote: post #16

Graal dev here. If you want to checkout all the sources/licenses of GraalVM CE. They are here: Graal: https://github.com/oracle/graal (GPLv2 with CPE) JavaScript with Node Integration: https://github.com/graalvm/graaljs (UPL - BSD license) Ruby: https://github.com/oracle/truffleruby (EPL, GPLv2, LGPL) R: https://github.com/oracle/fastr (GPLv2) Python: https://github.com/graalvm/graalpython (UPL - BSD license) LLVM/Su…

Can it also target bytecode or .jar artefacts, this way all JVM languages which compiles into JVM bytecode can be benefited

Re: GraalVM: Run Programs Faster Anywhere

#134

Post by mike_hearn »

truth_seeker wrote: post #133
grashalm wrote: post #16

Graal dev here. If you want to checkout all the sources/licenses of GraalVM CE. They are here: Graal: https://github.com/oracle/graal (GPLv2 with CPE) JavaScript with Node Integration: https://github.com/graalvm/graaljs (UPL - BSD license) Ruby: https://github.com/oracle/truffleruby (EPL, GPLv2, LGPL) R: https://github.com/oracle/fastr (GPLv2) Python: https://github.com/graalvm/graalpython (UPL - BSD license) LLVM/Su…

Can it also target bytecode or .jar artefacts, this way all JVM languages which compiles into JVM bytecode can be benefited

Yes, GraalVM is built on HotSpot so it can run all bytecode languages too.

Re: GraalVM: Run Programs Faster Anywhere

#135

Post by peoplewindow »

sandGorgon wrote: post #120
chrisseaton wrote: post #113

Earlier quoted context omitted.

It doesn't do that - we compile the Ruby interpreter to native, not the Ruby application. It's a little bit more complex than that in that we can run a Ruby application ahead of time up to a certain point where we compile it, and then when you run the application that state when it was compiled is restored. So we load the core library during compilation for example.

Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program? Will this be the case for truffle python, js,etc ?

I'm not on the Graal team but I can take a crack at an answer - it's because as languages get more dynamic, static ahead of time compilation becomes less and less effective and can even be counterproductive. To compile a Ruby program it really needs to be just-in-time compiled, or at least a partial ahead of time compile using injected profiling runs.

The problem is that the semantics of Ruby are such that you can't compile it efficiently out of the box. TruffleRuby can but only by making tons of assumptions at runtime that might not be valid. So it compiles code on the assumption your program is normal and not weird, and if those assumptions are violated, it goes back to interpreting the source code.

Therefore even if you could pre-compile Ruby in some pedantic sense, you'd still need the source code to fall back to when the JITC has to bail out.

Re: GraalVM: Run Programs Faster Anywhere

#136

Post by mike_hearn »

weberc2 wrote: post #68
bitL wrote: post #62

Earlier quoted context omitted.

Is it Oracle Oracle, or Oracle SUN product? BTW, it sounds pretty cool, I am wondering how do you convert between complex datatypes while passing parameters between different languages and not losing much speed with it?

Me too. I’m thinking there must be some library that knows how to marshal between object representations. Surely Graal doesn’t have universal objects that suit every language.

It has a form of universal object used for scripting languages (but not more static languages like Java or C++). But using it is not required, it's just a convenience to make implementing languages easier.

What it actually provides is a form of "universal abstract syntax tree". So if a C program wants to access a JavaScript object by writing "a->b = c" then the dereference is turned into a snippet of JavaScript code (in effect) and inlined right into the C function.

Re: GraalVM: Run Programs Faster Anywhere

#137

Post by mike_hearn »

saurik wrote: post #59

I have been paying some scant attention to GraalVM for some time, having been excited by "universal VMs" for decades now (including setups like LLVM, which most people forget was designed as a JIT-compiled VM, despite that being in the name), and I develop Cycript (which is somewhat the "opposite" technology, binding together existing virtual machines all into the same process space and doing crazy interop; though I…

Is there an existing embedding for node.js

That's what their "node" program actually is. It's regular node but using GraalVM instead of V8. The semantic difference you're getting at doesn't seem to exist.

I guess I was expecting a C/C++ API to be documented somewhere, not a Java API

SubstrateVM has a C API that can be used to start it up that's not the same as JNI, however, bear in mind Graal can be used as a plugin to regular HotSpot too. So you can just embed the JVM the usual way and ship the Graal compiler with it, enabled via a command line flag. So yes you can do this and it doesn't require any new documentation.

Re: GraalVM: Run Programs Faster Anywhere

#138

Post by holydude »

aardvark179 wrote: post #11
holydude wrote: post #3

This is seriously huge. I wonder if it actually gets popular. Can anyone comment on TruffleRuby ? What remains to be done for it to be production ready ? GraalVM page still mentions it's experimental.

We are getting there, lots of things work right out of the box just fine. C extensions are still being actively worked on as they often need some amount of patching because of assumptions they make about types and so forth. I think we can reduce that, but I doubt it can will disappear entirely, but in the end I hope extension authors will test on TruffleRuby themselves and patch the code themselves.

I know that you are using Rails as a reference point so is there any ETA when will be most of the features usable ? (openssl,activerecord,nokogiri..etc) ?

Re: GraalVM: Run Programs Faster Anywhere

#139

Post by mike_hearn »

_wmd wrote: post #21

Might this (today, tomorrow) become another way to get access to the wonderful Lucene from non-Java environments? A long, long time ago there was a GCJ-based solution, but it was never loved much (either the port or GCJ itself). SubstrateVM looks potentially delicious here edit: lol: talk about a low blow! > The community version does not support DWARF information. The enterprise version supports all native tools tha…

Well, there has always been JNI. If you want to access Lucene from C or runtimes that can call into C then you could do that for years.

Otherwise with GraalVM you could run your non-Java environments on Graal and go at it the other way around.

Re: GraalVM: Run Programs Faster Anywhere

#140

Post by mike_hearn »

royjacobs wrote: post #47

This is wonderful. I'm looking forward to playing around with JavaFX. Being able to compile that to a native image is huge! It would effectively invalidate the Electron approach of building "native" applications.

I don't think SubstrateVM supports JavaFX.

However bear in mind you can already bundle JavaFX and the JRE together into native installers for each platform that don't require a JRE or JVM, and don't mention Java anywhere, using the javapackager tool. I've used it several times, it works well enough.

Post reply on HN