Oracle Formally Proposes That Java Adopt Ahead-of-Time Compilation (infoworld.com)

An anonymous Slashdot reader quotes InfoWorld: Java applications will get faster startup times thanks to a formal proposal to include ahead-of-time compilation in the platform. The draft Java Development Kit proposal, authored by Vladimir Kozlov, principal technical staff member at Oracle, is targeted for inclusion in Java 9, which is expected to be available next summer. "We would love to see this make it into JDK 9, but that will of course depend on the outcome of the OpenJDK process for this JDK Enhancement Proposal," said Georges Saab, vice president of software development in the Java platform group at Oracle, on Thursday. Ahead-of-time compilation has been a stated goal for Java 9 to address the issue of slow startup...

The proposal summary notes that Java classes would be compiled to native code prior to launching the virtual machine. The ultimate goal is to improve the startup time of small or large Java applications while having "at most" a limited impact on peak performance and minimizing changes to the user workflow.
Tests indicates some applications perform better while some actually perform worse, so it's being proposed as an opt-in feature where dissatisfied users "can just rebuild a new JDK without ahead-of-time libraries."

Comments

Only makes sense for niches

[angel'o'sphere]

Penty of Enterprise software relies on byte code morphing/instrumentation and all things we get from Aspect Oriented Programming. Ahead of time compilation makes only sense in Applications that don't use such featers and should be simply part of the build process if developrs chose so and not necessarily a "language feature".
After all there are plenty of third party AoT Conpilers for the JVM.

Re:Only makes sense for niches

[lgw]

Reading comprehension skills, do you have them?

He uses Aspect Oriented Programming, so code is impossible to read and thus he doesn't practice reading comprehension much. (Also, Kirk could kick Picard's ass, and EMACS > VI).

Re: Only makes sense for niches

[WarJolt]

AOT makes sense for certain application. Also AOT doesn't mean AOT only. If you want to use it with a tracing JIT I see no reason why these technologies are incompatible.

The problem I have with Java is that with some java programs it takes less time for an equivalent C program to compile and run than an that java program to do all of its dynamic linking and finally run. You don't have to do AOT, but all those string compares during loading really slows things down. Each symbol has to be looked up and compared.

With native libraries often times shared libraries are already in memory. The libraries are simply mapped into a processes address space. In java land each time you load a library it takes up its own space and that overhead is not shared by multiple processes. It seems silly that these processes can't share their compilation efforts.

We have a ways to go with runtimes. The first step is oracle admitting they are the problem.

Already been done

[kelemvor4]

It's already been done. Symantec's compiler had a native compilation option. I build some things with old java revisions so I can use it. Like most native programs, it requires a runtime to be preinstalled. In the case of Symantec, it was the "symantec native java runtime". The most recent version I have is 3.0.

In conclusion, it's a good idea to have as an option. It's already been done, and I wonder if symantec has any patents that might get in the way of this being implemented on a broader scale.

Bullshit or bafflegab.

[BarbaraHudson]

The proposal summary notes that Java classes would be compiled to native code prior to launching the virtual machine.

If it's all compiled to native code ahead of starting the JVM, what do you need the JVM for? Their use of "native code" here is not what we usually mean. It's just "ahead-of-time" compiled libraries, same as the Android ART.

fantastic!

[Gravis Zero]

Oracle is just a misstep or two away from fully ruining Java. You couldn't ask for a better enemy.

Re:fantastic!

[gweihir]

Indeed. I hope they press on vigorously, because Java becoming unusable would be one of the best things that could happen to the IT world.

How is this different

[flargleblarg]

How is this different from just giving -server on the command line when invoking the JVM?

fix some other problems

[ooloorie]

There are a bunch of other problems with Java. Why not fix those at the same time as changing the compilation model?

We could call that new version of Java "Swift" or "C#".

Great, now I need a new Java joke

[Anonymous Coward]

I guess this means my favorite Java joke won't work anymore:
Knock knock.
Who's there?
.
.
.
.
.
.
Java

This raises the question

[overshoot]

Now that Oracle has figured out how to keep anyone from doing this without paying them, how much will they charge?

Re:Well, that clinches it.

[sexconker]

Joke post? Joke post.
The minute you need to call a library or access something the OS provides, you're fukt.

Re:Past-time Compilation

[BarbaraHudson]

You can use a pre-processor, with the right macros, to generate assembly language or even binary. Just depends on hacking the pre-processor.

Re:Idea

[BarbaraHudson]

You already need a bunch of different JVMs - sometimes even on the same machine. The translation to function calls for different OSes can be automated, same as any other cross-compiling.

Re:A real Java compiler?

[lgw]

This is about "ahead of time" compilation, otherwise known as "compilation", which third-party tools have done forever. Linking to C in Java is its own world, and I don't know how practical C++ is.

It's dead easy to bridge between C++ and C# at runtime using Managed C++ (or whatever they call it these days). The C# marshaller, the built-in way to get C objects from C# code, is slow painful garbage that no one should use, but it's easy to do the conversion in C++ and either object conversion or using objects directly is very fast that way.

You can compile C# to a proper EXE or DLLs easily enough and it will happily load C/C++ DLLs. The reverse is a bitch though - I've heard it's possible (the .NET runtime is also just DLLs), but I never got it to work properly.

You can (awkwardly) run C code from Java, including loading DLLs, but I've never heard it's possible to do the reverse. What can C code do with a JAR?

Linking all three would be a bragworthy project, but I think Java is just missing the key concept here.

Garbage

[speedplane]

I wish they'd spend more time on improving their garbage collectors than compilation time. It can take 30 seconds to a minute to garbage collect 25GB of memory, a huge problem for servers. The G1 garbage collector (G1GC) is promising, but it's still far to buggy to use in production. If this GC issue does not get fixed, I could see it incentivizing server software to switch to C/C++.

Re:Garbage

[binarylarry]

Or you could find developers that know what they're doing?

Re: A real Java compiler?

[lgw]

C++ just requires a thin C layer around the object oriented calls

Ah, yes, the "thin layer" that means you don't work directly with STL vectors, strings and maps, and, well, objects. Also, no exceptions. Bridging between an OOP language and an OOP language via C code means you need two awkward transitions between C-style code and OOP code.

I've done that far to many times. It can be quite constraining for your C++ code, depending on what kind of problem you're trying to solve. Also, that kind of marshaling is expensive. I've worked on plenty of Java codebases where 90% of CPU time was various serialization and deserialization code.

Well, better than nothing, but JNI was really intended to allow small chunks of C code to either do a bit of expensive calculation, or be a custom driver, or just wrap a system call that Java didn't, but in any case be a synchronous part of a Java function call. Much like C# with it's built-in marshaller, which punishes you for doing anything beyond wrapping system calls that the .NET runtime doesn't.

Ahead of time compiling?

[Anonymous Coward]

I've been trying out this new ahead of time compiling thing in an obscure language - 'C' This 'C' is like java, but without most of the "java.io.foo.bar.wibble.set(42)" syntactic bullshit and overall just feels less bloated. And 'C' doesn't require a multi-GB runtime. I only have to compile ahead of time once, not on every load, and best of all, I haven't *ever* had any exceptions thrown. It is like Java without the pain.

Java 16

[thinkwaitfast]

Java 16 will will be written entirely in executable machine code and will compile to source code.

Re: A real Java compiler?

[lgw]

Have you tried Managed C++? I've been through this 3 times now, and each time the team didn't believe me until we did the experiment. There's a quite nice boost in performance when your C++ code can, e.g., iterate through a list of strings as input without any copying or marshaling.

More complex classes require conversion or some tedious hand-coded wrappers, but we did a lot with just library containers, and the ability to just use C# objects directly from normal C++ code that knows nothing of .NET (thanks to some wrappers) is quite nice.

I also do this all the time between my C# (tools) code and C++ (game engine) code, and I've never found it constraining, although it's certainly tedious to recreate all the APIs in C. Creating a C-style interface for just about any C++ objects is reasonably straightforward if you break it down into handle (address of object) + method

The awkwardness depends a lot on whether your C++ style is "never (need to) explicitly clean up anything ever" code, or "C code with classes". If you're still doing the latter, catching exceptions and returning status codes, explicit clean-up code at the bottom of functions, or in destructors, that sort of thing, then it's not a big deal to make C-style wrappers.

OTOH, if you're using scoped objects and not in the habit of explicit clean-up, then it gets really awkward when you start doing stuff like: OK, I need to return an array. I can't return a pointer to my vector, since no shared pointers, so I'll have to copy it into a C-style array. Who's going to free that? Well, obviously, the caller should allocate it, and free it when appropriate, but how does the caller know how big to allocate? OK, I need another API function to just get the size, which is going to have to do all the same work. And so on and so on. All solvable, but you end up with a lot of copies being made, and a minefield for either leaks or dangling pointers if you don't completely understand how long the managed code is going to use that pointer you gave it.

So much easier for the C++ code to just take a reference to a vector as input, and never even realize it built a CLR List instead of a std::vector as it went (or, worst case, return a shared pointer to a vector, and copy it into a CLR list - less efficient, but no leaks or dangling pointers possible).