Live data from Hacker News

Ahead-of-Time Compilation

bugs.openjdk.java.net

91–95 of 95 posts

Re: Ahead-of-Time Compilation

#91

Earlier quoted context omitted.

I think you're ignoring the fact that there is lots of extra information available at runtime that isn't available from static analysis of languages even if they're very amenable to that, and that static analysis can actually give you worse information. For example a call site could be statically analysed to be bimoprhic, but then sometimes when you run it the second type is never actually used and the call site can…

> There is an implementation of the Ruby language called Rubinius that statically looks at the instance variables in a class that are visible in the source code, and optimises the objects for that many instance variables. If you start to set extra variables dynamically, and so upset this static analysis, performance drops by a half. You can implement an unsound static analysis for any language, and this in fact what…

> As you found out the hard way yourself.

That makes it sound like I implemented it - I didn't - I implemented the alternative mechanism which doesn't have the same problem.

Re: Ahead-of-Time Compilation

#92
post #50
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…

Yes, I'm familiar with SDE, but thanks for mentioning it. The SafeTSA I mentioned was one of Michael Franz's later contributions to the field. SafeTSA was an SSA representation capable of expressing all of the security and other semantic constraints of the Java language. Michael Franz's group took the Jikes RVM (then known as Japapeno) and added a second front-end to the JIT that could read SafeTSA, so they could test performance of programs running Java bytecode and SafeTSA in the same process. SafeTSA both took less time to go from bytecode to native code, but also the resulting native code ran faster.

Re: Ahead-of-Time Compilation

#93

> 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?

I would assume if the method is rarely called, but very complex or time-consuming when it is called.

Of course, I'm not an expert on JVMs, so I wouldn't know whether their analysis is synchronous or asynchronous or a mix of both.

Re: Ahead-of-Time Compilation

#94
post #89

Is there anything this adds over Scala-native, which seems to be much further ahead already?

I think this could be a great complement to Scala-native. Right now, the project contributors have to spend effort translating the essential Java libraries that would allow Scala-native to be successful. This could really ease that job for them. It could potentially make all the Java code ever written available to Scala-native. The other thing it adds is the backing of a giant, like Oracle, which can bring stability…

I think this assumes that Oracle

- can ship something in time

- and that it will be generally available for developers (looking at how hard Oracle pushes their Java department to invent commercial features they can sell, I'm not sure about that)

Looking at it, I assume that this will go the way of GWT ... not starting from "how can we make Java a good citizen in this new ecosystem?", but "here we have 100% of Java, the JDK and the JVM ... how can we compile this with full fidelity into X?".

Re: Ahead-of-Time Compilation

#95

Earlier quoted context omitted.

In benchmarks I've seen, Java already smokes Go on any benchmark except the second or so it takes the JVM to start up. I'm not aiming this just at you, but I think many people (node.js users in particular come to mind) don't realise just how good the JVM is, performance-wise. I'm not a great fan of Java the language, but the JVM is top class.

HotSpot can run hello world in about 50msec, not one second. A lot of people's views of JVM startup time are hopelessly out of date. The primary thing people seem to like about Go is that it produces single native binaries. You can do that with Java too (I gave an example of Avian further up the thread), but people don't tend to bother because distributing a single JAR is not much harder and avoids any assumptions ab…

Sorry, my Java startup time is also very out of date it seems. Thanks for the deeper detail.
Post reply on HN