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

GraalVM

graalvm.org

Post reply on HN
Print view View original

51–60 of 108 posts

Re: GraalVM

#51

Post by Erlich_Bachman »

galaxyLogic wrote: post #27
marta_morena_25 wrote: post #21

Earlier quoted context omitted.

> This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Outperform in what metric? Startup time? Granted. Anything else? Not so much. >Basically, it’s like switching from the JIT to a C compiler’s -O3. Yeah and that would be pretty bad (it's not a good analogy to begin with). "-O3" doesn't have anything that a JIT couldn't have. The only advantage is again, startup time. JIT compi…

> Startup time? Granted. Anything else? Not so much. Startup time matters a lot especially for Java applications. The reason Java never got to the desktop (including browser) I believe was the startup time. Startup time matters a lot also for micro-services. A 2nd great benefit of GraalVM I think is it makes it easy to integrate programs written in different languages, say Node.js and Java for instance.

> Java never got to the desktop (including browser)

What do you mean by this? There are a lot of desktop Java applications...

Re: GraalVM

#52

Post by mikkom »

galaxyLogic wrote: post #27
marta_morena_25 wrote: post #21

Earlier quoted context omitted.

> This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Outperform in what metric? Startup time? Granted. Anything else? Not so much. >Basically, it’s like switching from the JIT to a C compiler’s -O3. Yeah and that would be pretty bad (it's not a good analogy to begin with). "-O3" doesn't have anything that a JIT couldn't have. The only advantage is again, startup time. JIT compi…

> Startup time? Granted. Anything else? Not so much. Startup time matters a lot especially for Java applications. The reason Java never got to the desktop (including browser) I believe was the startup time. Startup time matters a lot also for micro-services. A 2nd great benefit of GraalVM I think is it makes it easy to integrate programs written in different languages, say Node.js and Java for instance.

> The reason Java never got to the desktop (including browser) I believe was the startup time.

I think it's mainly the fact that it has always been very difficult to create executable files.

Running java requires you to install the given version of JRE instead of just downloading an application and starting it.

Re: GraalVM

#53

Post by rkangel »

kasperni wrote: post #20

GraalVM consists of a couple of things. 1. A modern JIT compiler written in Java that takes bytecode and transforms it into machine code. There is a plan that it might someday replace HotSpot [1]. However, we are probably a couple of years away from this. 2. A native image compiler [2] that uses ahead-of-time compilation technology to produce executable binaries of class files. This means startup times and memory usa…

The 'party trick' combination of (2) and (3) being that you can take a Ruby application, and all of the C extensions that it's using, compile them all AoT and then run whole program optimisation. It was kinda/sorta working a couple of years ago I believe, I don't know what the progress has been.

Re: GraalVM

#54

Post by Hitton »

I have hard time being deeply invested in GraalVM considering that the most interesting stuff tends to be kept proprietary (e.g. profile-guided optimizations).

Re: GraalVM

#55

Post by fniephaus »

ridiculous_fish wrote: post #10

Can someone please give a sober explanation of what GraalVM, is and how Truffle works? I think it is somewhat analogous to LLVM: Graal exposes a "language agnostic" API which allows multiple front-ends. There's a front-end for Ruby, JS, C++, others. But this API is higher level than LLVM: it knows about objects, and allows tricks like querying properties across language boundaries. But I can't imagine what this API l…

> Can someone please give a sober explanation of what GraalVM, is and how Truffle works?

GraalVM is basically a JVM with a new compiler, the Graal compiler. Truffle is the language implementation framework for GraalVM and designed to build AST interpreter. The Graal compiler can optimize Truffle ASTs through partial evaluation (see "One VM to rule them all" paper [1]), and produces machine code directly without using Java bytecode as IR.

> how do JS semantics get expressed in a Java VM?

Graal.js comes with a parser for JavaScript code that generates a Truffle ASTs for a given JavaScript program. JS semantics are defined within the AST nodes (see [2]).

> What does a getProperty instruction look like?

I think getProperty is implemented in `CachedGetPropertyNode` [3], but I am not sure as there are multiple other property-related nodes.

> How does it know when to invalidate inline caches?

Unfortunately, Graal.js lacks documentation for `CachedGetPropertyNode`. But I encourage you to have a look at SimpleLanguage [4], a JS-like toy language and the reference language implementation for Truffle with proper documentation. [5] explains how reading properties and invalidating inline caches works and it's all done using the Truffle DSL. The `@Specialization` annotation [6] might be a good starting point if you want to learn how it works. You may also want to check out the docs on the GraalVM website (e.g. [7]).

[1] https://doi.org/10.1145/2509578.2509581

[2] https://github.com/graalvm/graaljs/tree/a36b978aa328a8da3a7f...

[3] https://github.com/graalvm/graaljs/blob/a36b978aa328a8da3a7f...

[4] https://github.com/graalvm/simplelanguage

[5] https://github.com/graalvm/simplelanguage/blob/a25e385dd8626...

[6] https://www.graalvm.org/truffle/javadoc/com/oracle/truffle/a...

[7] https://www.graalvm.org/docs/Truffle-Framework/user/README

Re: GraalVM

#56

Post by nathell »

kasperni wrote: post #20

GraalVM consists of a couple of things. 1. A modern JIT compiler written in Java that takes bytecode and transforms it into machine code. There is a plan that it might someday replace HotSpot [1]. However, we are probably a couple of years away from this. 2. A native image compiler [2] that uses ahead-of-time compilation technology to produce executable binaries of class files. This means startup times and memory usa…

[3] is made possible thanks to a variation of the idea called "Futamura projections":

https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...

Re: GraalVM

#57

Post by amelius »

Hitton wrote: post #54

I have hard time being deeply invested in GraalVM considering that the most interesting stuff tends to be kept proprietary (e.g. profile-guided optimizations).

Also, if you're like me, you simply don't want to deal with the law firm called Oracle.

Re: GraalVM

#58

Post by tosh »

TimTheTinker wrote: post #26
marta_morena_25 wrote: post #21

Earlier quoted context omitted.

> This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Outperform in what metric? Startup time? Granted. Anything else? Not so much. >Basically, it’s like switching from the JIT to a C compiler’s -O3. Yeah and that would be pretty bad (it's not a good analogy to begin with). "-O3" doesn't have anything that a JIT couldn't have. The only advantage is again, startup time. JIT compi…

As far as I know, Truffle is able to do some absolutely incredible compile-time optimizations —- reaching deeply into what we would normally regard as strictly semantic territory. (For an example, see some of the optimizations done by TruffleRuby for things like `myArray.sort.first` - which it apparently optimizes by terminating the sort as soon as the first element is sorted to the front of the array... and all that…

I'm not sure how it would terminate sort early, my initial assumption was that for small arrays there might be special-casing?

this seems to be a related thread on twitter:

https://twitter.com/ChrisGSeaton/status/1001582169578524672

Re: GraalVM

#59

Post by [deleted] »

marta_morena_25 wrote: post #21
hedora wrote: post #6

Earlier quoted context omitted.

Java’s linker is based on an open world assumption, where you can add arbitrary stuff to the classpath and dynamically link it at runtime. This defeats most compiler optimizations, so you’re left with the JIT. GraalVM makes a closed world assumption, so it can do things like dead code elimination (for library functions that don’t get called), and apply static analysis to inline virtual method calls, perform constant…

> This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Outperform in what metric? Startup time? Granted. Anything else? Not so much. >Basically, it’s like switching from the JIT to a C compiler’s -O3. Yeah and that would be pretty bad (it's not a good analogy to begin with). "-O3" doesn't have anything that a JIT couldn't have. The only advantage is again, startup time. JIT compi…

[deleted]

Re: GraalVM

#60

Post by rubyfan »

nathell wrote: post #56
kasperni wrote: post #20

GraalVM consists of a couple of things. 1. A modern JIT compiler written in Java that takes bytecode and transforms it into machine code. There is a plan that it might someday replace HotSpot [1]. However, we are probably a couple of years away from this. 2. A native image compiler [2] that uses ahead-of-time compilation technology to produce executable binaries of class files. This means startup times and memory usa…

[3] is made possible thanks to a variation of the idea called "Futamura projections": https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...

I read that as Futurama and when I clicked through was expecting to see a picture of Fry or Hypnotoad as some time travel concept as inspiration. Even better, when I clicked through I read it the first time and thought “wow cool someone’s last name is Futurama” then I read it again haha.
Post reply on HN