IBM User Guide for Java V7 on Windows > Troubleshooting and support > Using diagnostic tools > JIT and AOT problem determination > Diagnosing a JIT or AOT problem



Locating the failing method

When you have determined the lowest optimization level at which the JIT or AOT compiler must compile methods to trigger the failure, you can find out which part of the Java™ program, when compiled, causes the failure. You can then instruct the compiler to limit the workaround to a specific method, class, or package, allowing the compiler to compile the rest of the program as usual. For JIT compiler failures, if the failure occurs with -Xjit:optLevel=noOpt, you can also instruct the compiler to not compile the method or methods that are causing the failure at all.


Before you begin

If you see error output like this example, you can use it to identify the failing method: 

Unhandled exception
Type=Segmentation error vmState=0x00000000
Target=2_30_20050520_01866_BHdSMr (Linux 2.4.21-27.0.2.EL)
CPU=s390x (2 logical CPUs) (0x7b6a8000 RAM)
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=4148bf20 Signal_Code=00000001
Handler1=00000100002ADB14 Handler2=00000100002F480C InaccessibleAddress=0000000000000000
gpr0=0000000000000006 gpr1=0000000000000006 gpr2=0000000000000000 gpr3=0000000000000006
gpr4=0000000000000001 gpr5=0000000080056808 gpr6=0000010002BCCA20 gpr7=0000000000000000
......
Compiled_method=java/security/AccessController.toArrayOfProtectionDomains([Ljava/lang/Object;
Ljava/security/AccessControlContext;)[Ljava/security/ProtectionDomain;

The important lines are:

vmState=0x00000000
Indicates that the code that failed was not JVM runtime code.
Module= or Module_base_address=
Not in the output (might be blank or zero) because the code was compiled by the JIT, and outside any DLL or library.
Compiled_method=
Indicates the Java method for which the compiled code was produced.

If your output does not indicate the failing method, follow these steps to identify the failing method:


Tasks

  1. Run the Java program with the JIT parameters verbose and vlog=<filename> added to the -Xjit or -Xaot option. With these parameters, the compiler lists compiled methods in a log file named <filename>.<date>.<time>.<pid>, also called a limit file. A typical limit file contains lines that correspond to compiled methods, like: 
    + (hot) java/lang/Math.max(II)I @ 0x10C11DA4-0x10C11DDD
    Lines that do not start with the plus sign are ignored by the compiler in the following steps and you can remove them from the file. Methods compiled by the AOT compiler start with + (AOT cold). Methods for which AOT code is loaded from the shared class cache start with + (AOT load).

  2. Run the program again with the JIT or AOT parameter limitFile=(<filename>,<m>,<n>), where <filename> is the path to the limit file, and <m> and <n> are line numbers indicating the first and the last methods in the limit file that should be compiled. The compiler compiles only the methods listed on lines <m> to <n> in the limit file. Methods not listed in the limit file and methods listed on lines outside the range are not compiled and no AOT code in the shared data cache for those methods will be loaded. If the program no longer fails, one or more of the methods that you have removed in the last iteration must have been the cause of the failure.

  3. Optional: If you are diagnosing an AOT problem, run the program a second time with the same options to allow compiled methods to be loaded from the shared data cache. You can also add the –Xaot:scount=0 option to ensure that AOT-compiled methods stored in the shared data cache will be used when the method is first called. Some AOT compilation failures happen only when AOT-compiled code is loaded from the shared data cache. To help diagnose these problems, use the –Xaot:scount=0 option to ensure that AOT-compiled methods stored in the shared data cache are used when the method is first called, which might make the problem easier to reproduce. Please note that if you set the scount option to 0 it will force AOT code loading and will pause any application thread waiting to execute that method. Thus, this should only be used for diagnostic purposes. More significant pause times can occur with the –Xaot:scount=0 option.

  4. Repeat this process using different values for <m> and <n>, as many times as necessary, to find the minimum set of methods that must be compiled to trigger the failure. By halving the number of selected lines each time, you can perform a binary search for the failing method. Often, you can reduce the file to a single line.


What to do next

When you have located the failing method, you can disable the JIT or AOT compiler for the failing method only. For example, if the method java/lang/Math.max(II)I causes the program to fail when JIT-compiled with optLevel=hot, you can run the program with: 

-Xjit:{java/lang/Math.max(II)I}(optLevel=warm,count=0)
to compile only the failing method at an optimization level of "warm", but compile all other methods as usual.

If a method fails when it is JIT-compiled at "noOpt", you can exclude it from compilation altogether, using the exclude={<method>} parameter: 

-Xjit:exclude={java/lang/Math.max(II)I}

If a method causes the program to fail when AOT code is compiled or loaded from the shared data cache, exclude the method from AOT compilation and AOT loading using the exclude={<method>} parameter: 

-Xaot:exclude={java/lang/Math.max(II)I}
AOT methods are compiled at the "cold" optimization level only. Preventing AOT compilation or AOT loading is the best approach for these methods.


Parent: Diagnosing a JIT or AOT problem

Previous topic: Selectively disabling the JIT or AOT compiler

Next topic: Identifying JIT compilation failures








Error 404 - Not Found

Error 404 - Not Found

The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.