Oracle Formally Proposes That Java Adopt Ahead-of-Time Compilation (infoworld.com) 104
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."
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."
Only makes sense for niches (Score:4, Informative)
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 (Score:5, Funny)
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: (Score:2)
Re: Only makes sense for niches (Score:5, Interesting)
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.
Re: (Score:2)
it takes less time for an equivalent C program to compile and run
No kidding. I have a pretty sophisticated self-specializing application that we rely on in my lab. It occasionally needs to create a semi-custom C program to run a particular computation with new parameter settings. It's so fast to generate the few thousand lines of C code and compile them that you barely notice the times when it needs to spin a new specialization of the code versus running an already-compiled version.
Re: (Score:2)
If the C program was equivalent it had a comparable amount of files/classes.
There is no way it compiles remotely as fast than a Java program, sorry.
Dynamic loaded classes are of course not shared in Java processes, unlike *.so's or *.DLL's. However if a JVM links in a native *.so it is of course shared like any other process.
We have a ways to go with runtimes. The first step is oracle admitting they are the problem.
Why those exaggerations? We have no problem.
The applications that start up super slow are *.E
Re: Only makes sense for niches (Score:2)
Breaking that kind of coffee is the best reason for making this mandatory I can think of.
Re: (Score:2)
Re: (Score:2)
Because Aspect oriented programming and bytecode inspection produce unreadable, unmaintainable codebases. It shouldn't be done, ever. We've known for decades that self modifying code is a bad idea, if you use it you're bad.
Re: (Score:2)
That is nonsense.
You don't see the manipulated byte code, and aspect oriented code is clearly readable as object oriented code.
The only slight problem is e.g. generated code by hibernate or the spring framework while you are debugging. But for that you simply right click on the relevant code in the stack frame and make it "invisible" (forgot the correct name of the command), then the debugger simply steps over framework code.
We've known for decades that self modifying code is a bad idea, if you use it you'r
Re: (Score:2)
"Ahead-of-time compilation"? That's like "compilation" isn't it, the thing that's been used to build code since 1952?
Oracle announces more than half-century old technology as new feature of Java! Press ecstatic! Slashdot reports! And then the next day reports the same thing again! And then a third time just to be sure!
Re: (Score:2)
In principle Java is "ahead of time" compiled to byte code.
And during execution on most platforms "just in time" compiled to native code.
The announcement is about compiling directly to native code, which makes only in rare cases sense.
A real Java compiler? (Score:2)
If it's 'just in time' to make your app perform, does that make it a JIT compiler?
Next: I need to link between Java, C++ and C# modules.
Re: (Score:2)
does that make it a JIT compiler?
Java already has a JIT compiler, which is why startup times are slow. This proposal if for an AOT - Ahead Of Time - compiler.
Re: (Score:3)
This is about "ahead of time" compilation, otherwise known as "compilation", which third-party tools [stackoverflow.com] 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 object
Re: A real Java compiler? (Score:2)
Linking to C and C++ is fairly easy. JNI is a bit clunky but not hard to understand. C++ just requires a thin C layer around the object oriented calls
Re: A real Java compiler? (Score:4, Insightful)
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.
Re: (Score:2)
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. As for exceptions, game development generally doesn't use them (in native code), but yes, that would require each native method to wrap the API function in a try-catch block
Re: (Score:3)
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
Re: (Score:2)
I haven't tried managed C++, but it sounds interesting (if I hadn't already done all the work).
I'm using modern C++ everywhere, but I still haven't found the transition to a C-style interface too onerous in most cases. As you surmised, the most awkward sections tend to be when dealing with C++ types passed around at the interface level. My typical approach is to transform the data into a structure that works in the managed code. For instance, my engine works natively with UTF-8 strings, so I need to conv
Re: (Score:2)
One other thing to look at is shared memory as a "transport". I did very fast IPC between C# and some kernel-mde C code (initiated from the C# side) once - yeah, still some serialization, since you can't use raw pointers, but not a lot.
Re: (Score:2)
That's actually how my interprocess communication library handles the details underneath the interface (the Windows FileMapping API). And yep, it's extremely fast.
Re: (Score:2)
I wish I worked on anything where that sort of performance mattered these days. Other challenges, sure, but not as fun.
Re: (Score:2)
"If performance is an issue, then it may be a sign that your interop API may be a bit too fine grained"
Therein lies the problem though, sometimes you have little choice but for that to be the case and in those circumstances managed to native marshalling is incredibly expensive.
I had some old legacy code I had to take on board that used native Lua as a scripting language, and the cost of marshalling between executions of Lua scripts was incredibly expensive - there wasn't really anything you could batch, the
Re: (Score:2)
STL isn't OOP though, and is no disadvantage if you can't use it.
Re: (Score:2)
Are you being an academic purist insisting nothing but Smalltalk is real OOP? Otherwise I don't get your point,
Re: (Score:2)
It's one of the major criticisms when STL was introduced. It's based on templates and not objects. You can't easily subclass a template, and definitely not STL containers. STL doesn't fit into most definitions of OOP, academic or not.
Re: (Score:1, Informative)
This is about "ahead of time" compilation, otherwise known as "compilation", which third-party tools [stackoverflow.com] have done forever. Linking to C in Java is its own world, and I don't know how practical C++ is.
The stack overflow you link to has nothing to do with AOT. They all use a standard JVM and JARs, just all packaged into a single exe file. Its still JIT for the ones that include the JRE bits, the others just download and install a JRE for you. Using C and C++ code from Java is non-trivial but easy enough.
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.
Its just as easy in Java, except better hidden, cause you're not supposed to do it, in order to keep the 'cross platform' nature of Java at its core. Microsoft wants you to bind your C# apps to the Win
Re: (Score:1)
> 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?
It's pretty straightforward to run Java from a C program (or it was about 10 years ago, when I worked on a project which needed it): if you think about it, it's what the "java.exe" does. Once the JVM is launched inside your code, then you can run code within it.
Already been done (Score:3)
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.
Re: (Score:2)
Re: Already been done (Score:1)
Cycle of life (Score:1)
Google steals from Oracle. Oracle steals from Google.
This sounds like ART on Android device, with the ahead of time compilation. Google has moved away from the AOT mechanism for apps because updates became a pain for end users. In Nougat, they use a "hybrid" approach, where the code that is executed most frequently gets compiled while your device is idle. So, some code will run JIT and others as compiled pieces.
This might not be as big of a concern for enterprise products.
Bullshit or bafflegab. (Score:4, Interesting)
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.
Re: (Score:2)
It's just "ahead-of-time" compiled libraries, same as the Android ART.
Say what? From wikipedia:
Unlike Dalvik, ART introduces the use of ahead-of-time (AOT) compilation by compiling entire applications into native machine code upon their installation.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You are wrong. You need the run time because it provides services such as GC and profiling.
At install time, ART compiles apps using the on-device dex2oat tool. This utility accepts DEX files as input and generates a compiled app executable for the target device.
The # of SoCs is neither here not there. You need to have the ART compiled to the specific SoC, when you do that you can make the AOT module generate native code for the specific SoC if you so wish.
I'm not an expert on ART, but I'm pretty sure you are wrong on this one.
Re: (Score:2)
Re: (Score:2)
It's not as good as "real" native code. The performance is shit in comparison. Do a search for writing android apps in c/c++. Even Microsoft supports this for Android in their free Visual C compiler. ART is a bit better tha dalvik, but it's still terribly slow. Think of it - we had better response on a 386 single core 40 mhz with 8 megs of ram. And nothing;s going to fix that, including "compiling sections to native code".
Java is slow. Android is even slower. Using the ART as a shim to go between native co
Re: (Score:1)
Re: (Score:1)
Just because a preprocess to machine code program has not been written does not mean that it cannot be done or that the preprocessor cannot "shift languages". The C99 preprocessor can act as a Turing complete language. See the post by Paul Fultz II @ http://stackoverflow.com/questions/3136686/is-the-c99-preprocessor-turing-complete
Re: (Score:2)
Re: (Score:3)
fantastic! (Score:5, Insightful)
Oracle is just a misstep or two away from fully ruining Java. You couldn't ask for a better enemy.
Re:fantastic! (Score:4, Insightful)
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.
Re: (Score:1)
How so?
Re: (Score:2)
eh, that's a tiny misdeed by Oracle compared to their big crimes.
Auditors storming a company, demanding their black box audit scanning code be run with access to all networks, claiming any virtual hosting platform in any location of the company might be used to run Oracle DBMS so must pay the license fees for all of them (or else buy Oracle hardware at somewhat less an amount of extortion).....
They've become a bunch of mafia thugs in the "protection money" racket. =Avoid doing business with Oracle, or ta
Re: (Score:2)
I don't care about Oracle because they are a self-defaming company. I do care about which language that projects are written in and Java is not a winner.
How is this different (Score:3)
Idea (Score:1)
What if Java just let you compile for each system individually. I mean it would be a bit of a pain for software engineers to manage all those versions of java apps but think of the performance increases.
Re: (Score:3)
Re: (Score:2)
.NET already supports this, but it has it's downsides too. For starters it breaks things like reflection, and as such it's not something that can simply be done for "free". It's something you do on a case by case basis - the reality is that performance isn't everything and there are always other factors to weigh in, sometimes performance loses, sometimes it wins, but you certainly can't assume performance always trumps every other factor.
Well, that clinches it. (Score:1)
There's now officially no benefit to using Java.
"Write once, run anywhere" was a pipe dream from the beginning.
I never saw why compiling for different platforms was a problem. If you write in 99% ANSI C/C++ then portability is not a big deal!
Re: (Score:3)
Joke post? Joke post.
The minute you need to call a library or access something the OS provides, you're fukt.
Re: (Score:2)
fix some other problems (Score:3)
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 (Score:4, Funny)
I guess this means my favorite Java joke won't work anymore:
Knock knock.
Who's there?
.
.
.
.
.
.
Java
Re: (Score:1)
That's probably McAfee in the way.
"ahead of time compilation" (Score:1)
So, just "compilation"?
This raises the question (Score:3)
Re: (Score:2)
Tachyons (Score:1)
I'm sure OnLive tried to harness the power of tachyons.
It did not go well. They failed before getting anywhere.
Garbage (Score:5, Informative)
Re: Garbage (Score:1)
Re: (Score:2)
As an admin who had done a enough of java tuning i would suggest you to run more small instances behind a load balancer
I'm already running plenty of relatively large instances. Decreasing the instance size requires that I add many more instances, which create other problems. It would be nice if Java could be run efficiently on larger servers (e.g., >32GB of RAM).
Re:Garbage (Score:4, Insightful)
Or you could find developers that know what they're doing?
Re: (Score:2)
Re: (Score:2)
ARC results in much lower latency when cleaning up memory. This results in better user interfaces and helps explain why it works well with iOS. The JVM employs garbage collection that offers better performance at the cost of higher latency. If you load balance multiple instances (as suggested by another poster) you get overall improved performance. The JVM is better suited for server applications where its garbage collection implementation is safer and requires less overall energy to perform a given jo
Re: (Score:2)
Re: (Score:2)
Ahead of time compiling? (Score:2, Funny)
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.
its... (Score:2)
Java 16 (Score:5, Funny)
Oracle is the problem (Score:2)
If Oracle genuinely cared about Java, they would release it, and the patents to the community.
You'd literally be insane to touch it at the moment. Oracle will step on too many toes eventually, and the more toes they step on, the bigger the risk of using Java long term is. They have a long history of being d**ks, but the most recent I remember, is when they forked Redhat to make their own distro, which was basically exactly the same, but a few minor kernel tweaks, and that users paid Oracle instead of Redhat
Excellent -- This allows light wieght processes (Score:2)
If JITing can be done up front and cached, and the Jited code shared between processes, this would make it feasible to run short lived processes that do specific tasks in a light weight manner. And that means avoiding the monolithic Java web serving processors.
The Java rhetoric has always been that creating processes is slow. Which is true, for Java. But not for C programs on *nix. DB connection is more of an issue.
Sure, there is some overhead in running up a PHP-like process, but for small to medium lo
I've seen this before (Score:2)
Isn't this what the Jalapeno project did?
Does this solve a real problem? (Score:1)
Not trolling - could you give me an example?
I work with Java every day, both for tooling and end products. The Java startup times are never a factor. What takes time is dependency management, loading of plugins, synchronization between systems etc, and you are likely to have them using any language. The time from initiating the process to the first line of Java code being executed is hardly measurable in the context.
Re: (Score:2)
NGEN (Score:1)