I want to download a JIT compiler for Java. Where can I get a good JIT compiler?
The JIT compiler runs as part as the JVM - it's not something you download and run separately.
In the early days of Java, you used to be able to run a JIT as a plugin - but these days there's no need. Any mainstream, modern desktop Java environment will include a JIT.
Most of the JVMs have a JIT built in. Download any of them.
My guess is you are looking for a java to native .exe compiler in the mistaken belief that this will yield a significant performance difference. For Java this is not the case for most real applications and just makes deploying them harder.
Any modern well-performing Java implementation comes with a JIT, and normally you do not have to worry about these kind of things. The most frequent is the Oracle Java implementation available from http://java.com.
If you, however, have a performance problem it is usually a problem with your own code, so use a suitable profiler (jvisualvm in the Sun 6 JDK is a good, free starting point) to identify your bottlenecks, so you can correct them.
Related
I was recently comparing the JVM and CLR platforms and was discussing the impact of JIT compilation. The discussion I was having led to .NET's ability to precompile code using the NGen tool, which would eliminate the need for JIT compilation. Is there an equivalent in the Java platform?
The native compiler that I've heard the most about is Excelsior JET - Java Virtual Machine and Native Compiler. See http://www.excelsior-usa.com/jet.html for more details. Basically you can turn your project into a single executable without the hassles of the usual Java packaging.
They have been around for a long time (they where here when I joined the Java ranks in 2001 and they are here now. I just heard a week ago how a company is using their solution are and are happy with it.
About couple of years ago at JavaONE I also met a developer or two of the product and they told me that they are live and kicking and doing well.
I'm not aware of any, personally (you can look at options like launch4j, jexe, etc, they are just wrappers, not like NGen), and I'm not sure how feasible it would be... The answer to this question goes into some details on the subject of compiling to native code: Differences in JIT between Java and .Net
Yes. As of Java 9, you can. The feature you are looking for is called Ahead of Time (AOT) compilation.
There are two main JVMs in use today:
HotSpot (and it's variants), which is the main JVM from Oracle.
OpenJ9, originally from IBM.
OpenJ9
In OpenJ9, just run the Java Virtual Machine with the -Xshareclasses:persistent option. This causes the VM to store compiled binaries into a cache, which persists across system boots. It does not force the Java VM to use the precompiled code in all cases, as in many cases Just In Time (JIT) code can execute faster. The JVM will pick whether to use the cached binary or not on a case by case basis. When a cached AOT method is run it might also be optimized further by the Just-In-Time (JIT) compiler.
Full details are available at:
https://www.eclipse.org/openj9/docs/aot/
https://www.eclipse.org/openj9/docs/xshareclasses
HotSpot (OpenJDK)
The HotSpot (OpenJDK) builds now include an experimental VM that can completely precompile everything, called GraalVM. You manually create native binaries using the jaotc executable. Note: this is currently only available on Linux (and possibly Mac) systems.
Details on how to use the jaotc compiler are at:
https://docs.oracle.com/javase/10/vm/java-hotspot-virtual-machine-performance-enhancements.htm#JSJVM-GUID-F33D8BD0-5C4A-4CE8-8259-FD9D73C7C7C6
https://openjdk.java.net/jeps/295 (this includes an example where you generate and use an AOT library for the java.base module).
Note: jaotc is not as simple to use as the OpenJ9 shared classes flag.
I need to use Java for a desktop application. I heard that there are many tools that compile java natively, is this true? does these tools compile java program into machine code?
THank you!
Since the (Sun/Oracle) Java VM has a good JIT (just-in-time) compiler, you don't have to compile your Java program to machine code yourself. The compiler will do that on the fly when it's necessary.
So: Speed up your Java programs just as every other program:
reduce algorithmic complexity
exploit parallelism
compute at the right moment
find and remove bottlenecks
...
Since Java is a garbage collected language, there is one important point to more speed: reduce allocations! Reducing allocations will help you at least twice: The allocation itself isn't done and the garbage collector will have to do less work (which will save time).
I agree with the others that compiling to machine code does not make much sense: mind that C free/malloc have same or higher costs than Java new/garbage collection.
The NetBeans IDE comes with a built-in Profiler; so you could profile your application in that IDE to find bottlenecks.
are you coding the app or it's someone's else?
It looks you're trying to run an java app that is slow. Try increasing the memory when running it. You can change the shell script specifying these params:
java -Xms64m -Xmx512m
I need to use Java for a desktop application. I heard that there are
many tools that compile java natively, is this true? does these tools
compile java program into machine code?
Such programs do exist, but may come with tradeoffs when using some of the more dynamic capabilities of the Java platform like you may lose the ability to load new classes at runtime. The JVM may have a slow start up, but it's plenty fast enough once it gets going.
That said, one solution that I didn't see anyone mention here is to replace code written in Swing with SWT. The SWT toolkit uses native code underneath.
As far as I understand Java compiles to Java bytecode, which can then be interpreted by any machine running Java for its specific CPU. Java uses JIT to interpret the bytecode, and I know it's gotten really fast at doing so, but why doesn't/didn't the language designers just statically compile down to machine instructions once it detects the particular machine it's running on? Is the bytecode interpreted every single pass through the code?
The original design was in the premise of "compile once run anywhere". So every implementer of the virtual machine can run the bytecodes generated by a compiler.
In the book Masterminds for Programming, James Gosling explained:
James: Exactly. These days we’re
beating the really good C and C++
compilers pretty much always. When you
go to the dynamic compiler, you get
two advantages when the compiler’s
running right at the last moment. One
is you know exactly what chipset
you’re running on. So many times when
people are compiling a piece of C
code, they have to compile it to run
on kind of the generic x86
architecture. Almost none of the
binaries you get are particularly well
tuned for any of them. You download
the latest copy of Mozilla,and it’ll
run on pretty much any Intel
architecture CPU. There’s pretty much
one Linux binary. It’s pretty generic,
and it’s compiled with GCC, which is
not a very good C compiler.
When HotSpot runs, it knows exactly
what chipset you’re running on. It
knows exactly how the cache works. It
knows exactly how the memory hierarchy
works. It knows exactly how all the
pipeline interlocks work in the CPU.
It knows what instruction set
extensions this chip has got. It
optimizes for precisely what machine
you’re on. Then the other half of it
is that it actually sees the
application as it’s running. It’s able
to have statistics that know which
things are important. It’s able to
inline things that a C compiler could
never do. The kind of stuff that gets
inlined in the Java world is pretty
amazing. Then you tack onto that the
way the storage management works with
the modern garbage collectors. With a
modern garbage collector, storage
allocation is extremely fast.
Java is commonly compiled to machine instructions; that's what just-in-time (JIT) compilation is. But Sun's Java implementation by default only does that for code that is run often enough (so startup and shutdown bytecode, that is executed only once, is still interpreted to prevent JIT overhead).
Bytecode interpretation is usually "fast enough" for a lot of cases. Compiling, on the other hand, is rather expensive. If 90% of the runtime is spent in 1% of the code it's far better to just compile that 1% and leave the other 99% alone.
Static compiling can blow up on you because all the other libraries you use also need to be write-once run everywhere (i.e. byte-code), including all of their dependencies. This can lead to a chain of compilations following dependencies that can blow up on you. Compiling only the code as (while running) the runtime discovers it actually needs that section of code compiled is the general idea I think. There may be many code paths you don't actually follow, especially when libraries come into question.
Java Bytecode is interpreted because bytecodes are portable across various platforms.JVM, which is platform dependent,converts and executes bytecodes to specific instruction set of that machine whether it may be a Windows or LINUX or MAC etc...
One important difference of dynamic compiling is that it optimises the code base don how it is run. There is an option -XX:CompileThreshold= which is 10000 by default. You can decrease this so it optimises the code sooner, but if you run a complex application or benchmark, you can find that reducing this number can result in slower code. If you run a simple benchmark, you may not find it makes any difference.
One example where dynamic compiling has an advantage over static compiling is inlining "virtual" methods, esp those which can be replaced. For example, the JVM can inline up to two heavily used "virtual" methods, which may be in a separate jar compiled after the caller was compiled. The called jar(s) can even be removed from the running system e.g. OSGi and have another jar added or replace it. The replacement JAR's methods can then be inlined. This can only be achieved with dynamic compiling.
Q.1. What free compiler produces the most optimal Java bytecode?
Q.2. What free virtual machine executes Java bytecode the fastest (on 64-bit multi-core CPUs)?
Q.3. What other (currently active) compiler projects are missing from this list:
http://www.ibm.com/developerworks/java/jdk/
http://gcc.gnu.org/java/
http://openjdk.java.net/groups/compiler/
http://java.sun.com/javase/downloads/
http://download.eclipse.org/eclipse/downloads/
Q.4. What performance improvements can compilers do that JITs cannot (or do not)?
Q.5. Where are some recent benchmarks, comparisons, or shoot-outs (for Q1 or Q2)?
Thank you!
Q.1. What free compiler produces the fastest executable Java bytecode?
Question doesn't really make sense. The bytecode is not executed. The compiled bytecode will not be different enough to influence the efficiency of the produced machine code when using a good JIT.
Q.2. What free virtual machine executes Java bytecode the fastest (on 64-bit multi-core CPUs)?
This is a better question. I believe it's JRockit
Q.3. What other (currently active) compiler projects are missing from this list:
http://www.ibm.com/developerworks/java/jdk/
http://gcc.gnu.org/java/
http://openjdk.java.net/groups/compiler/
http://java.sun.com/javase/downloads/
http://download.eclipse.org/eclipse/downloads/
I believe you missed out JRockit. But for a more complete list, I'd look at Wikipedia: List of Java Virtual Machines. Looking up whether or not they're active should be an easy task.
Q.4. What performance improvements can compilers do that JITs cannot (or do not)?
Technically none I suppose. The bytecode compilation is basically the wrong place to put the effort when it comes to optimization.
Q.5. Where are some recent benchmarks, comparisons, or shoot-outs (for Q1 or Q2)?
Google is your friend here. These are two:
http://jmob.ow2.org/jvm/RUBiS.html
http://jmob.ow2.org/jvm/VolanoMark.html
unfortunately those don't cover that many VMs.
Q.4. What performance improvements can compilers do that JITs cannot (or do not)?
A JIT compiler can perform global optimizations. A bytecode compiler cannot do this because it cannot see all of the libraries that are loaded during the running of the program.
A JIT compiler can perform branch optimizations based on the observed behavior of the current program execution. A bytecode compiler cannot do this because by the time the program starts running the compiler is already out of the picture.
The only viable alternative to javac at the moment is the Eclipse compiler.
Have a look at it. Question is what you have found to be inefficient and if it really matters.
I know that you can run almost all Java in Dalvik's VM that you can in Java's VM but the limitations are not very clear. Has anyone run into any major stumbling blocks? Any major libraries having trouble? Any languages that compile to Java byte code (Scala, Jython etc...) not work as expected?
There is a number of things that Dalvik will not handle or will not handle quite the same way as standard Java bytecode, though most of them are quite advanced.
The most severe example is runtime bytecode generation and custom class loading. Let's say you would like to create some bytecode and then use classloader to load it for you, if that trick works on your normal machine, it is guaranteed to not work on Dalvik, unless you change your bytecode generation.
That prevents you from using certain dependency injection frameworks, most known example being Google Guice (though I am sure some people work on that). On the other hand AspectJ should work as it uses bytecode instrumentation as a compilation step (though I don't know if anyone tried).
As to other jvm languages -- anything that in the end compiles to standard bytecode and does not use bytecode instrumentation at runtime can be converted to Dalvik and should work. I know people did run Jython on Android and it worked ok.
Other thing to be aware of is that there is no just in time compilation. This is not strictly Dalviks problem (you can always compile any bytecode on the fly if you wish) but that Android does not support that and is unlikely to do so. In the effect while microbenchmarking for standard Java was useless -- components had different runtime characterstics in tests than as parts of larger systems -- microbenchmarks for Android phones totally make sense.
If you see "Dalvik Virtual Machine internals" Google IO session, you can find Dalvik does not support generational GC.
So, it could degrade performance of frequent object creation and deletion. Java VM supports generational GC so, it would show better GC performance for the same situation.
And also, Dalvik uses trace-granuality JIT instead of method granuality JIT.
Another thing that I guess could be added here is that Dalvik apparently does not preserve field order when listing the fields of a class using the reflection API. Now, the reflection API does not make any guarantees on it anyway (so ideally you shouldn't depend on it anyway), but most of the other VMs out there do preserve the order.
Just to add to the conversation, not intended to revive an old thread. I just ran across this in my search, and want to add that Jython does not work out of the box with Dalvik either. Simply trying to do a hello world example will yield the following: