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

61–70 of 95 posts

Re: Ahead-of-Time Compilation

#61

Post by amelius »

vidarh wrote: post #50
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…

You might be interested in looking at Semantic Dictionary Encoding [1]. It was professor Michael Franz' PhD thesis work. Franz' was Andreas Gals advisor on his thesis on trace trees. SDE didn't propose starting with SSA, but could easily work with an SSA representation. SDE basically functions as a compression mechanism for an semantic IR that builds a dictionary on compression/decompression reminiscent of LZW. So in…

Interesting. Do you have a link to the thesis? The link on wikipedia seems broken, and Franz's homepage doesn't seem to contain a link.

Re: Ahead-of-Time Compilation

#62

Post by pjmlp »

catnaroek wrote: post #55
h4nkoslo wrote: post #14

Earlier quoted context omitted.

Most of the JIT optimizations amount to "it's been called like this in the past; assume it'll always be & depotimize (at a penalty) if it isn't." That potentially includes the fully resolved types of objects (ie devirtualization), branch prediction (stronger than the CPU can do; for instance, if a value is only used inside a branch that's never taken, don't bother mutating it), data sizes (this "array" is only ever s…

> assume it'll always be & depotimize (at a penalty) if it isn't Stuff like this makes me nervous. Performance is already a complex topic, and stuff like this makes it even more complex. Unnecessarily so. If we were talking about a very high-level programming language (say, Prolog), you could argue that the expressiveness benefits outweigh the cost of the runtime system's complexity. But Java isn't even as expressive…

Hence why we have projects Valhala and Panama.

However bringing those features to Java and the JVM specification, while keeping existing code running, is a big engineering effort, which is why they are targeting Java 10+.

I would have like that back in those days, Gosling and his team would have taken the inspiration from Modula-3, Oberon, Component Pascal and many others.

But better later than never, and regarding Java 10 time frame, I am happy they aren't doing a Python break the world thing.

Re: Ahead-of-Time Compilation

#63

Post by pjmlp »

srean wrote: post #58
vidarh wrote: post #52

Earlier quoted context omitted.

Yes, but that locks you in to optimising for whatever you covered with your profiling. If the character of your data changes, it'll take a recompile to change how the application performs, while a JIT can potentially choose to deoptimise/reoptimise. I'm all for "as static as possible" toolchains, but there are optimization opportunities you simply won't have with AOT, PGO or not. E.g. consider something trivial: A pr…

In theory yes, but sadly i have never seen that promise realized in any consistent fashion. Same goes for Java's escape analysis. Although the principle is sound i think the engineering required is horrendously difficult to make it robust. In a very narrow window of variation it works, but should you step out of that zone it fails pretty badly. I think it will take many more years, till then pgo and metaprogramming i…

Regarding escape analysis, beware that the OpenJDK is the worst of them all.

IBM J9, Graal are much better at it, and I bet Aonix, Azul and other JDKs targeting high performance deployment scenarios are even better.

Re: Ahead-of-Time Compilation

#64

Post by pjmlp »

Matthias247 wrote: post #57
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.

Go still has the feature of lightweight threads (goroutines) by default and great communication and synchronization primitives (channels, select) between them. For Java you still have to choose either real threads or from one of dozens of not-necessarily-compatible async IO frameworks (Netty, Grizzly, ...). How much that really matters depends on the type of your application. There's also emulation of Gos concurrency…

Java also has green threads.

The JVM specification doesn't require OS threads, and in the early days all JVMs only had green threads.

Nowadays you can still get such JVMs, just not the OpenJDK.

Re: Ahead-of-Time Compilation

#65

Post by cybernet »

amelius wrote: post #61
vidarh wrote: post #50

Earlier quoted context omitted.

You might be interested in looking at Semantic Dictionary Encoding [1]. It was professor Michael Franz' PhD thesis work. Franz' was Andreas Gals advisor on his thesis on trace trees. SDE didn't propose starting with SSA, but could easily work with an SSA representation. SDE basically functions as a compression mechanism for an semantic IR that builds a dictionary on compression/decompression reminiscent of LZW. So in…

Interesting. Do you have a link to the thesis? The link on wikipedia seems broken, and Franz's homepage doesn't seem to contain a link.

The name of the paper is "Code-Generation On-the-Fly: A Key to Portable Software" just search for it.

Re: Ahead-of-Time Compilation

#66

Post by the8472 »

srean wrote: post #59
the8472 wrote: post #38

Earlier quoted context omitted.

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 i…

Indeed. Another issue is that java semantics is too rigidly defined. Compilers of many other languages have a lot more room in deciding order of evaluation, vectorization etc

Java tries to provide semi-sane behavior even in the presence of data races. Carefully constructed code can give you benign behavior even under racy data accesses.

If you relaxed some compiler constraints, e.g. allowed it to re-read local variables because they were discarded due to register pressure then those benign races would suddenly turn into non-benign ones.

Re: Ahead-of-Time Compilation

#67

Post by pjmlp »

KMag wrote: post #51
pjmlp wrote: post #34

Earlier quoted context omitted.

> 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...).

There has also been gcj for a long time, but default toolchains matter a lot.

GCJ was abandoned in 2009 as the majority of its devs left to either work on Eclipse's compiler or early OpenJDK days.

It is still available on gcc, because of its unit tests. Some gcc code paths are only used by gcj.

Re: Ahead-of-Time Compilation

#68

Post by Asooka »

pjmlp wrote: post #34
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...).

Those are priced for people who already made a big investment in writing their application in Java and now realise they need features not present in javac. If you're just starting out, it can very well make more sense to use Microsoft Visual C++, which costs less than a commercial Java compiler and comes with an IDE that's light years ahead of anything available to Java developers.

Desktop Java also had many other problems, which can be summarised as "the JVM is its own OS". You can't write an application in Java that has a native look and feel. Or at least you couldn't for the first several significant years of its life and even now I don't think there's a good story for writing a simple native application. Meanwhile you could grab wxWidgets or Qt (and there goes your budget for a java compiler) and have a native-looking cross-platform application. Which very few did, because back then Mac OSX didn't exist, Apple were on their death bed and "Linux Desktop Environment" was even more of a joke than it is today.

So yeah, it didn't make any bit of sense to develop Java desktop apps given that you already had a large pool of proficient C++ developers, the only platform you cared about was Windows and Java GUI libraries insisted on reinventing their own look and feel. Oh and you could always just buy Delphi if you didn't want to suffer C++ (again, for a fraction of the price of a commercial Java compiler).

Nowadays people wrap a bunch of javascript in an electron instance, but this only happened after the web took off and nobody really looks at native desktop apps much. If this AOT work can give us fully contained native executables that we can distribute without having the user install Java and with significantly better performance than nodejs, maybe Java on the desktop can still happen.

Re: Ahead-of-Time Compilation

#69

Post by the8472 »

catnaroek wrote: post #55
h4nkoslo wrote: post #14

Earlier quoted context omitted.

Most of the JIT optimizations amount to "it's been called like this in the past; assume it'll always be & depotimize (at a penalty) if it isn't." That potentially includes the fully resolved types of objects (ie devirtualization), branch prediction (stronger than the CPU can do; for instance, if a value is only used inside a branch that's never taken, don't bother mutating it), data sizes (this "array" is only ever s…

> assume it'll always be & depotimize (at a penalty) if it isn't Stuff like this makes me nervous. Performance is already a complex topic, and stuff like this makes it even more complex. Unnecessarily so. If we were talking about a very high-level programming language (say, Prolog), you could argue that the expressiveness benefits outweigh the cost of the runtime system's complexity. But Java isn't even as expressive…

> With proper use of algebraic data types and pattern matching, unreachable branches can be kept to a minimum, or even outright eliminated in many cases.

Those would still result in branches. speculative optimizations can turn the common case into branch-free code that uses traps in the uncommon ones to bail out. But since those things are often data-dependent you can't just bake them in at compile-time.

Re: Ahead-of-Time Compilation

#70

Post by jgalt212 »

> Infrequently-used Java methods might never be compiled at all, potentially incurring a performance penalty due to repeated interpreted invocations.

That sort of makes no sense. How can you incur a real performance hit if the uncompiled method is rarely called?

Post reply on HN