Running native profiling on AIX
Read the information provided
-
<!-- -->Introduction
-
AIX provides a debug extension to the malloc subsystem for debugging memory allocation errors and native memory leaks. This extension activates trace points in the malloc routines and records allocations that are not subsequently freed. This tool can be used to identify the source of leaking native memory in the Java process.
<!-- -->Running AIX debug malloc for a Java process
-
As AIX debug malloc is built into the malloc routines, you do not have to install additional tooling or utilities. To activate AIX debug malloc, set the following environment variable:
MALLOCDEBUG=[trace,output:malloc.out,report_allocations,verbose,stack_depth:3]
where the options have the following meanings:
trace Activate tracing of the malloc subsystem. output Specify tracing to a log file; in this case, malloc.out. report_allocations Report outstanding allocations when the application stops. stack_depth Report outstanding allocations with the specified stack depth; in this case, 3. Notes:
- The stack depth of 3 provides only a limited stack trace. However, the use of larger stack depths with a Java application can cause crashes because the debug malloc facility does not understand the stack frames used for JIT compiled code.
- Some of these options are available only in AIX 5.3
The following developerWorks article describes the usage of AIX debug malloc and provides a simple script to combine similar stack traces: http://www.ibm.com/developerworks/aix/library/au-mallocdebug.html?ca=dgr-lnxw82MALLOCDEBUG
<!-- -->Example of AIX debug malloc output
-
When the Java process stops, a report is written to either stdout or to the specified file, in the following format:
Allocation #1111: 0x3174BC68 Allocation size: 0x400 Allocation traceback: 0xD02F4370 malloc 0x31791258 Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 0x301A477C ?? Allocation #1112: 0x3174C078 Allocation size: 0x400 Allocation traceback: 0xD02F4370 malloc 0x31791258 Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 0x301A477C ?? Allocation #1113: 0x3174C488 Allocation size: 0x400 Allocation traceback: 0xD02F4370 malloc 0x31791258 Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 0x301A477C ?? Allocation #1114: 0x3174C898 Allocation size: 0x400 Allocation traceback: 0xD02F4370 malloc 0x31791258 Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 0x301A477C ?? Allocation #1115: 0x3174CCA8 Allocation size: 0x400 Allocation traceback: 0xD02F4370 malloc 0x31791258 Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 0x301A477C ?? Allocation #1116: 0x3174D0B8 Allocation size: 0x400 Allocation traceback: 0xD02F4370 malloc 0x31791258 Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 0x301A477C ?? Allocation #1117: 0x3174D4C8 Allocation size: 0x400 Allocation traceback: 0xD02F4370 malloc 0x31791258 Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 0x301A477C ??
This example shows the allocations made by the Java process that was not freed at the point that the Java processes ended. The Java Virtual Machine itself makes a number of allocations at startup that persist for the lifetime of the JVM and are never freed. Ignore the first 1000 allocations to account for this startup allocation. Any subsequent allocation is a potential leak suspect.