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

A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

youtube.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#31

Post by marvy »

pvg wrote: post #24
chrisseaton wrote: post #21

Earlier quoted context omitted.

> to me this case is still a JIT jittin' I think the point is that some JITs never do this kind of optimisation - they just produce the same code an AOT compiler would, but at runtime. Such as the .NET JIT.

I don't think that's the point the comment I'm replying to is making, or at least, it's not the point I'm asking about. Edit: Your example in the other comment about the locks is the sort of thing I'm asking about. There, an optimization is made which is sound under some specific conditions and then unmade when those conditions change.

I think that is indeed the point pron was making, or at least similar. You can't actually ignore soundness, but JVMs sometimes go farther than I'd expect. (Example: don't check for null, just handle SIGBUS if null is "very rare")

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#32

Post by pvg »

marvy wrote: post #31
pvg wrote: post #24

Earlier quoted context omitted.

I don't think that's the point the comment I'm replying to is making, or at least, it's not the point I'm asking about. Edit: Your example in the other comment about the locks is the sort of thing I'm asking about. There, an optimization is made which is sound under some specific conditions and then unmade when those conditions change.

I think that is indeed the point pron was making, or at least similar. You can't actually ignore soundness, but JVMs sometimes go farther than I'd expect. (Example: don't check for null, just handle SIGBUS if null is "very rare")

Yes, on re-reading the thread again it might be entirely (or almost) about language. As in, it's really something along the lines of 'The power of the JIT approach comes from runtime information and dynamism. But you can also be a 'just' a JIT without making use of any of that'. And I'm getting stuck on 'secret weapon [...] soundness' and imagining some unfathomable-to-mortals ninja something.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#33

Post by pron »

twic wrote: post #28
pron wrote: post #11

Earlier quoted context omitted.

12 is the current JDK version. OpenJDK has no notion of LTS (e.g. you will see no mention of 11 being an LTS on the project page: https://openjdk.java.net/projects/jdk/11/ nor any special designation compared to JDK 12's page), and all versions are equal. Java's LTS means something that could perhaps be quite different from LTS in other projects. LTS is a service offered by companies to arbitrary JDK versions of thei…

> OpenJDK has no notion of LTS But two of the main maintainers, Oracle and Red Hat, absolutely do. > LTS is a service offered by companies to arbitrary JDK versions of their choice And that arbitrary version is 11. It's technically accurate but substantially disingenuous to suggest that 11 is not Java's current LTS.

> But two of the main maintainers, Oracle and Red Hat, absolutely do.

BTW, Oracle contributes ~90% and Red Hat ~5%.

> It's technically accurate but substantially disingenuous to suggest that 11 is not Java's current LTS.

Either way that has little significance here. It is not the most popular version of Java in use today (that would be 8u2XX) nor is it any more production-ready or stable than 12. You can say that we're interested in results for the current version of Java or in the most popular one. I don't understand why it would be particularly interesting to discuss JDK 11, which is neither.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#34

Post by lewurm »

chrisseaton wrote: post #4
_lbaq wrote: post #3

Just in time compilation, I think it should be called “continuous profile guided compilation” instead, describes better the awesomeness that happens...

Some people differentiate between just-in-time compilation , which is what for example .NET does (or did, last time I checked), where it just literally compiles it as it would ahead-of-time, but at the last second before executing it for the first time, and dynamic compilation , which is for example what Graal does - compiling based on runtime conditions, possibly multiple times with different results as the program…

> [...] which is what for example .NET does.

.NET is the platform. There are different implementations for it doing different things.

JIT compilation is still different to AOT even without profile guided optimizations. Simple example: In AOT code you can't embed pointers easily and is often solved with indirection (e.g. something like GOT in ELF).

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#35

Post by pron »

pvg wrote: post #29
ddragon wrote: post #27

Earlier quoted context omitted.

I guess it depends on the perspective and interpretation of soundness. If a JIT-compiler AoT compiles your entire program but infers that your function that implements logic that works for every number (as you defined it using the Number interface within the rules of it's type system) will only use 32 bits integers, then it will compile code that effectively does not hold up to the property that was established. The…

It could be and that would be uninteresting. But it's not hard to come up with a (contrived, limit-casey) optimization approach that does actually make guesses about soundness. Let's say you wanted to optimize a short instruction sequence with a small domain of inputs. You could try to generate all (or at least, zillions) of similarly-sized possible instruction sequences and check them for soundness and performance.…

All the time, and BTW, I didn't say JITs sacrifice soundness but that they don't require proof of soundness. That's different as I'll show.

Let me give you two common examples: virtual calls and branches. A JIT will speculatively devirtualize and inline a virtual call at a particular callsite if it has only encountered one or a small number of concrete instances, even if it can't prove that those are the only instances that can be encountered at that callsite. This is still sound because the JIT will emit a trap that will trigger if an unknown target is ever encountered, in which case it will deoptimize the compilation, go back to the interpreter and then compile again under new assumptions. Another example is branch elimination. If a JIT only ever encounters the program taking one side of a branch, it will only compile that branch (and introduce a trap), even if it can't prove that only that side will ever be taken.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#36

Post by yogthos »

As a side note, GraalVM is quite usable for real world stuff nowadays. Here's an example of running a Clojure web service with Graal that provides JSON endpoints, talks to the database, and does session management: https://github.com/yogthos/graal-web-app-example

The same app can be run on the JVM or compiled statically using Graal. The JVM version takes around a 100 megs of RAM, and has a significant startup time. The Graal version weighs in at 7 megs, and starts up instantly.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#38

Post by pvg »

pron wrote: post #35
pvg wrote: post #29

Earlier quoted context omitted.

It could be and that would be uninteresting. But it's not hard to come up with a (contrived, limit-casey) optimization approach that does actually make guesses about soundness. Let's say you wanted to optimize a short instruction sequence with a small domain of inputs. You could try to generate all (or at least, zillions) of similarly-sized possible instruction sequences and check them for soundness and performance.…

All the time, and BTW, I didn't say JITs sacrifice soundness but that they don't require proof of soundness. That's different as I'll show. Let me give you two common examples: virtual calls and branches. A JIT will speculatively devirtualize and inline a virtual call at a particular callsite if it has only encountered one or a small number of concrete instances, even if it can't prove that those are the only instanc…

Thanks! I did (eventually) figure it out, I initially misread it as something like:

1. Jettison soundness

2. ???

3. Performance profit.

Which seems like witchcraft, then again JITs are full of witchcraft. But it's also not what you wrote. I've now come to understand the two chief weapons of the JIT remain surprise, fear, ruthless efficiency and an almost fanatical devotion to the Pope.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#39

Post by pjmlp »

chrisseaton wrote: post #21
pvg wrote: post #19

Earlier quoted context omitted.

Maybe I'm getting tripped up in the terminology here but to me this case is still a JIT jittin' - you look at runtime data and decide it's worth it to crank out a special case optimization for the input of 2. You produce that that optimization, which is sound along with a check to make sure it is applied only in the special case. You get to defer other optimization. The advantage here still seems to come from the run…

> to me this case is still a JIT jittin' I think the point is that some JITs never do this kind of optimisation - they just produce the same code an AOT compiler would, but at runtime. Such as the .NET JIT.

I guess you need to update your knowledge regarding the several .NET JITs in use.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#40

Post by pjmlp »

repolfx wrote: post #8

From what I know, GraalVM EE (Enterprise Edition) does do loop vectorisation. This will lead to an interesting problem if they want to replace C2 with Graal. Are they willing to regress performance for some open-source-only users, even if it's a performance win for others?

OpenJDK for Java 12 also does it, as Intel has contributed AVX optimizations to it.
Post reply on HN