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

41–50 of 108 posts

Re: GraalVM

#41

Post by [deleted] »

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…

[deleted]

Re: GraalVM

#43

Post by sriku »

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…

There's also an expectation that memory footprint will be lower and that can contribute to speed by reducing GC time. The "JIT can do it too" arguments generally don't consider bounded memory.

Re: GraalVM

#45

Post by fniephaus »

andretti1977 wrote: post #40

I'm happy with language interoperability as a concept but how can i mix java and js in the same codebase with graalvm? And would it make sense? What are the advantages of this approach?

Currently, you'd use the polyglot package that ships with the GraalVM SDK:

https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Con...

Here are a couple of demos:

https://github.com/graalvm/graalvm-demos

I said "currently", because you currently have to use the host Java, that is the Java on top of which all other languages are implemented. The GraalVM team is working on Project Espresso, a Java written in Truffle. That will make polyglot programming with Java much more consistent with the rest of the languages. Project Espresso isn't public yet, but here's the latest update from the team working on it:

https://github.com/oracle/graal/issues/1656#issuecomment-664...

Re: GraalVM

#46

Post by toyg »

nwmcsween wrote: post #2

Does graalvm work with openjdk or any java VM alternative? And does Graalvm have the weird Oracle no business use license that Oracle Java has?

GraalVM is “open core”: the community edition is free as in freedom, but the enterprise version (which you need for any serious production usage) is commercial and “Oracle expensive”.

It’s a bit of a shame, because it’s really nice tech, but it will likely continue to struggle for adoption as long as it’s owned by Oracle. I wish they would spin it off; the same product, with more or less the same commercial model, would probably work very well in the market, as long as it lived far away from the the toxic Oracle-licensing nightmare.

Re: GraalVM

#47

Post by Turbots »

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…

Outperform in terms of startup time and memory footprint.

Starting up a complete Spring MVC + Netty web stack in 0.018 seconds with roughly 60-100Mb of memory is pretty cool for container runtimes like Kubernetes. Can reduce cost A LOT in cloud environments and makes way for proper function/event based architectures where scaling down to 0 or scaling up to hundreds of instances for burst use cases is required.

It does this mostly by doing ahead of time compilation, eliminating dead code and putting all the static code on a stack which gets loaded into memory at startup.

This has some implications: - reflection is nearly impossible to use in this scenario - you can't do anything funky in static code blocks like initialize a database or something weird like that - the JIT compiler of the JVM is not present so it cannot do hot code path optimizations at runtime, meaning the native image performance of SubstrateVM is slower than in the JIT compiler. So if you want performance and throughput, stick to the JIT compiler (GraalVM has a really good one written in Java itself, or use the standard Hotspot one by Oracle, OpenJDK or other vendors)

Re: GraalVM

#48

Post by secondcoming »

pjmlp wrote: post #23
smabie wrote: post #14

Earlier quoted context omitted.

In my experience, native image is noticeably slower than regular openjdk, at least for Scala. The start up speed is nice, though.

Twitter thinks otherwise, as they are the major consumer of GraalVM in production.

What part of production, do you know? Because mobile.twitter.com links are slow as hell to load

Re: GraalVM

#49

Post by pjmlp »

secondcoming wrote: post #48
pjmlp wrote: post #23

Earlier quoted context omitted.

Twitter thinks otherwise, as they are the major consumer of GraalVM in production.

What part of production, do you know? Because mobile.twitter.com links are slow as hell to load

Twitter has a couple of talks about it.

https://jaxenter.com/graalvm-chris-thalinger-interview-16307...

Post reply on HN