Recently I did some benchmarking with the HotSpot and because my program was obviously too slow, I began to browse the HotSpot sources for some secret  tuning parameters that could save my day. And indeed, after some digging, I found a real big fish: the "-Xintelligent_as_can_be_execution" option.

Well, sounds extremely promising, I thought by myself, and started some experiments. For your convenience, I'll reproduce here the small factorial program, that I used to measure performance:

import java.math.BigInteger;

public class Factorial {

  public static BigInteger factorial(long l) {
    BigInteger result = BigInteger.ONE;
    BigInteger fac = BigInteger.ONE;
    while (l-- > 0) {
      result = result.multiply(fac);
      fac = fac.add(BigInteger.ONE);
    return result;

  public static void main(String args[]) {
    long l = args.length > 0 ? Long.parseLong(args[0]) : 1;
    long t1 = System.currentTimeMillis();
    System.out.println("Factorial " + l + " = " + factorial(l));
    System.err.println("Elapsed time = " + 
                       (System.currentTimeMillis() - t1) + "ms");

I compiled the program and started Java on the console (I redirected the output of the resulting number to /dev/null to display only the elapsed time):

> java Factorial 10000 >/dev/null
Elapsed time = 2579ms

Now the same program with the secret "-Xintelligent_as_can_be_execution" option. Big expectations...

> java -Xintelligent_as_can_be_execution Factorial 10000 >;/dev/null
Elapsed time = 14930ms

...big frustration. The execution time has increased by a factor of five! What's wrong here? If you can't belive it, just trust me and try the option with your preferred application. A performance degradation is guaranteed.

But what is this intelligence option good for, if it only slows down a program? So I started further investigations and found another very interesting, undocumented (and therefore probably extremely striking) option: "-Xcompletely_brain_damaged_execution". Seems counterintuitive, but if the "-Xintelligent_as_can_be_execution" option slows the program down, perhaps the "-Xcompletely_brain_damaged_execution" option will accelerate execution time up to infinity?

> java -Xintelligent_as_can_be_execution \
       -Xcompletely_brain_damaged_execution Factorial 10000 >/dev/null
Elapsed time = 2599ms

Well, not exactly brilliant, but at least the brain damage option seems to compensate for the intelligence option. Finally I decided to abandon the search for secret high performance options and back-doors intended only for the use by the coalition of the willing and other registered secrete services and just went on improving my own program...


This is my first blog on and I thought I'll start with something funny..


If you didn't knew the two secret options discussed just before you don't have to be upset. The funny thing is that they really work as described (I hope you tried them out), but as in the majority of cases, there's a really trivial explanation for this phenomena.

As you probably know, the HotSpot VM supports some extended options, among them "-Xint" and "-Xcomp". The first one runs the VM in an interpreter-only mode (without JIT compilation) while the latter advises the VM to compile all Java methods before executing them. For some reason (probably accidentally - or intentionally if you like to belive in conspiracy), the HotSpot programmers decided to match the original options against the beginning of a given command line argument (in fact they use strncmp() with the length argument being set to the length of the original option). Therefore, the "-Xintelligent_as_can_be_execution" option is recognized as "-Xint" while the "-Xcompletely_brain_damaged_execution" option is identified as "-Xcomp".

Obviously, the execution of a program in interpreter-only mode is considerably slower than the execution in mixed mode (which is the default mode). On the other hand, "-Xint" and "-Xcomp" are mutually exclusive options. If they are given both on the command line, the last one wins. That's why in the last example, we ended in the compile-all mode. Usually, the execution time in this mode is slightly slower than in mixed mode, because each and every Java method will be JIT-compiled. In our small example however, the execution time was similar to the one in mixed mode.