Selectively disabling the JIT or AOT compiler

If your Java™ program failure points to a problem with the JIT or AOT compiler, you can try to narrow down the problem further.

About this task

By default, the JIT compiler optimizes methods at various optimization levels. Different selections of optimizations are applied to different methods, which are based on their call counts. Methods that are called more frequently are optimized at higher levels. By changing JIT compiler parameters, you can control the optimization level at which methods are optimized. You can determine whether the optimizer is at fault and, if it is, which optimization is problematic.

The AOT compiler by default compiles methods at the warm optimization level. Forcing the AOT compiler to compile a method at a higher level is possible, but not supported.

You specify JIT parameters as a comma-separated list, which is appended to the -Xjit option. The syntax is -Xjit:<param1>,<param2>=<value>. For example:
java -Xjit:verbose,optLevel=noOpt HelloWorld
runs the HelloWorld program, enables verbose output from the JIT, and makes the JIT generate native code without performing any optimizations. Optimization options are listed in -Xjit. The AOT compiler is controlled in a similar manner, by using the -Xaot option. Use the -Xjit option when you are diagnosing JIT compiler problems, and the -Xaot option when you are diagnosing AOT compiler problems.

Follow these steps to determine which part of the compiler is causing the failure:


  1. Set the JIT or AOT parameter count=0 to change the compilation threshold to zero. This parameter causes each Java method to be compiled before it is run.
    Use count=0 only when you are diagnosing problems, because a lot more methods are compiled, including methods that are used infrequently. The extra compilation uses more computing resources and slows down your application.
    With count=0, your application fails immediately when the problem area is reached. In some cases, using count=1 can reproduce the failure more reliably.
  2. Add disableInlining to the JIT or AOT compiler parameters.
    disableInlining disables the generation of larger and more complex code.
    If the problem no longer occurs, use disableInlining as a workaround while the Java service team analyzes and fixes the compiler problem.
  3. Decrease the optimization levels by adding the optLevel parameter, and run the program again until the failure no longer occurs, or you reach the noOpt level. For a JIT compiler problem, start with scorching and work down the list. For an AOT compiler problem, start with warm and work down the list.
    The optimization levels are, in decreasing order:
    1. scorching
    2. veryHot
    3. hot
    4. warm
    5. cold
    6. noOpt

What to do next

If one of these settings causes your failure to disappear, you have a workaround that you can use. This workaround is temporary while the Java service team analyze and fix the compiler problem. If removing disableInlining from the JIT or AOT parameter list does not cause the failure to reappear, do so to improve performance. Follow the instructions in Locating the failing method to improve the performance of the workaround.

If the failure still occurs at the noOpt optimization level, you must disable the JIT or AOT compiler as a workaround.