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

Ahead-of-Time Compilation

bugs.openjdk.java.net

Post reply on HN
Print view View original

31–40 of 95 posts

Re: Ahead-of-Time Compilation

#31

Post by CalChris »

BuckRogers wrote: post #21

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way. I always got the sense the world is waiting for a statically typed Python that c…

I remember that HotSpot was promising faster than GCC -O2. This sort of over promising was good for presentations to the Schmidt and McNealy types.

Re: Ahead-of-Time Compilation

#32

Post by j-g-faustus »

BuckRogers wrote: post #21

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way. I always got the sense the world is waiting for a statically typed Python that c…

Because Java was originally designed for set-top TV boxes and appliances, where it's kind of a big deal that you don't need to know or care what OS or processor each appliance is using internally.

https://web.archive.org/web/20050420081440/http://java.sun.c...

When the appliance market didn't pan out, they went for web browsers and Java applets. Bytecodes were a feature because browsers didn't exectute native code, and because it allowed for sandboxing to limit the attack surface.

Even when Java became more popular on the server than in the browser, the "write once, run everywhere" was considered a major feature: The same bytecode could be distributed everywhere; no need to maintain a heap of different build environments for different CPU architecture and OS combinations.

Re: Ahead-of-Time Compilation

#34

Post by pjmlp »

KMag wrote: post #18

This is great news, though it initially only supports Linux x86-64 and is decades late for Java desktop apps (and not having non-blocking I/O until Java 1.4 was shameful for a language explicitly targeted and a pervasively networked ecosystem.) In their "tiered mode", they put sampling instrumentation into the native code, and if they detect a hotspot, regenerate fully instrumented native code from bytecode using the…

> decades late for Java desktop apps

Commercial JDKs always offered AOT compilation, the problem is that people nowadays apparently don't buy compilers anymore unless forced to do so (e.g. embedded, consoles...).

Re: Ahead-of-Time Compilation

#35

Post by pjmlp »

chc wrote: post #5
taspeotis wrote: post #2

I can't see anywhere in the linked issue that indicates AOT compilation is coming to Java 9, or even coming at all. The issue demonstrates nothing more than an intent to bring it to OpenJDK, and the issue seems to be very nascent? It was only created a fortnight ago. Lest the title is changed: AOT compilation is coming to Java 9 (java.net) 18 points by hittaruki 37 minutes ago

The person who created this ticket is an Oracle employee, not some random Joe, so it seems like a reasonable guess that it's something Oracle is planning.

They are planning it, and there were already several talks, but the roadmap was Java 10 or later.

Re: Ahead-of-Time Compilation

#36

Post by CalChris »

qznc wrote: post #30
jcheng wrote: post #23

Earlier quoted context omitted.

For several of Java's early use cases, being able to deploy a single file that could be run on any Java-supported platform was very important. https://en.wikipedia.org/wiki/Write_once,_run_anywhere

Also, a small file and stack based bytecode is often the most compact representation.

This is true and small memory sizes and limited bandwidth were design assumptions valid in 1992.

Re: Ahead-of-Time Compilation

#37

Post by pjmlp »

Cyph0n wrote: post #9

Assuming this comes in Java 9, and compilation of code other `java.base` is possible, will this make Java a more solid competitor to Go? I guess it partly depends on how much they optimize the compiled binary size. Go does a really good job at static compilation, so it will be tough to compete.

Java has AOT compilation since ages, here is one example.

https://www.excelsiorjet.com/

Most commercial JDKs do support AOT compilation to native code, and alongside Java library and eco-system, it definitely makes it more than a solid competitor to Go.

The problem is that free AOT compilers never were a big match to the ones from commercial JDKs, and in this day and age, most developers don't pay for compilers unless forced to do so.

So Java AOT compilers are usually only used by enterprise companies.

Re: Ahead-of-Time Compilation

#38

Post by the8472 »

CalChris wrote: post #31
BuckRogers wrote: post #21

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way. I always got the sense the world is waiting for a statically typed Python that c…

I remember that HotSpot was promising faster than GCC -O2. This sort of over promising was good for presentations to the Schmidt and McNealy types.

My understanding is that GCC has a more diverse arsenal of optimizations that it can apply to code while hotspot has the advantage that it can profile at runtime and apply speculative optimizations based on those profiles and bail out later if things change. In principle it can even optimize code that never reaches steady state as long as the transient states last long enough.

What costs java performance these days is not the quality of the JIT compilers or even the garbage collectors. It's the object layout that is not very cache-friendly. There is lots of pointer-chasing going on since there are no arrays-of-structs.

Valhalla[0] promises to improve the data layout issue at some point in the future while graal may allow compiler writers to cram some more optimizations into the jits.

[0] http://openjdk.java.net/projects/valhalla/

Re: Ahead-of-Time Compilation

#39

Post by pjmlp »

BuckRogers wrote: post #21

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way. I always got the sense the world is waiting for a statically typed Python that c…

Religion.

Talking about AOT compilation at Sun was tabu and I remember seeing a few forum discussions from former employees disclosing this.

Plenty of other platforms do support bytecodes, JIT and AOT on the same toolchain.

So they could keep the WORA story and still offer AOT as an option, which actually most commercial JDKs do.

Re: Ahead-of-Time Compilation

#40

Post by pjmlp »

j-g-faustus wrote: post #32
BuckRogers wrote: post #21

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way. I always got the sense the world is waiting for a statically typed Python that c…

Because Java was originally designed for set-top TV boxes and appliances, where it's kind of a big deal that you don't need to know or care what OS or processor each appliance is using internally. https://web.archive.org/web/20050420081440/http://java.sun.c... When the appliance market didn't pan out, they went for web browsers and Java applets. Bytecodes were a feature because browsers didn't exectute native code, a…

Plenty of other platforms do support bytecodes, JIT and AOT on the same toolchain.

So they could keep the WORA story and still offer AOT as an option, which actually most commercial JDKs do.

Just Sun was against providing it at all on Java SE, but they actually supported it on Java Embedded.

Post reply on HN