IBM User Guide for Java V7 on Windows > Reference > Command-line options > JVM command-line options > -Xcheck option

-Xcheck:memory

Identifies memory leaks inside the JVM.

-Xcheck:memory[:<option>]

Identifies memory leaks inside the JVM using strict checks that cause the JVM to exit on failure. If no option is specified, all is used by default. The available options are as follows:

all

Enables checking of all allocated and freed blocks on every free and allocate call. This check of the heap is the most thorough. It typically causes the JVM to exit on nearly all memory-related problems soon after they are caused. This option has the greatest affect on performance.

callsite=<number of allocations>

Displays callsite information every <number of allocations>. De-allocations are not counted. Callsite information is presented in a table with separate information for each callsite. Statistics include:

• The number and size of allocation and free requests since the last report.
• The number of the allocation request responsible for the largest allocation from each site.

Callsites are presented as sourcefile:linenumber for C code and assembly function name for assembler code.

Callsites that do not provide callsite information are accumulated into an "unknown" entry.

failat=<number of allocations>

Causes memory allocation to fail (return NULL) after <number of allocations>. Setting <number of allocations> to 13 causes the 14th allocation to return NULL. De-allocations are not counted. Use this option to ensure that JVM code reliably handles allocation failures. This option is useful for checking allocation site behavior rather than setting a specific allocation limit.

ignoreUnknownBlocks

Ignores attempts to free memory that was not allocated using the -Xcheck:memory tool. Instead, the -Xcheck:memory statistics that are printed out at the end of a run indicates the number of "unknown" blocks that were freed.

mprotect=<top|bottom>

Locks pages of memory on supported platforms, causing the program to stop if padding before or after the allocated block is accessed for reads or writes. An extra page is locked on each side of the block returned to the user.

If you do not request an exact multiple of one page of memory, a region on one side of your memory is not locked. The top and bottom options control which side of the memory area is locked. top aligns your memory blocks to the top of the page (lower address), so buffer underruns result in an application failure. bottom aligns your memory blocks to the bottom of the page (higher address) so buffer overruns result in an application failure.

Standard padding scans detect buffer underruns when using top and buffer overruns when using bottom.

nofree

Keeps a list of blocks that are already used instead of freeing memory. This list, and the list of currently allocated blocks, is checked for memory corruption on every allocation and deallocation. Use this option to detect a dangling pointer (a pointer that is "dereferenced" after its target memory is freed). This option cannot be reliably used with long-running applications (such as WebSphere Application Server), because "freed" memory is never reused or released by the JVM.

noscan

Checks for blocks that are not freed. This option has little effect on performance, but memory corruption is not detected. This option is compatible only with subAllocator, callsite, and callsitesmall.

quick

Enables block padding only and is used to detect basic heap corruption. Every allocated block is padded with sentinel bytes, which are verified on every allocate and free. Block padding is faster than the default of checking every block, but is not as effective.

skipto=<number of allocations>

Causes the program to check only on allocations that occur after <number of allocations>. De-allocations are not counted. Use this option to speed up JVM startup when early allocations are not causing the memory problem. The JVM performs approximately 250+ allocations during startup.

subAllocator[=<size in MB>]

Allocates a dedicated and contiguous region of memory for all JVM allocations. This option helps to determine if user JNI code or the JVM is responsible for memory corruption. Corruption in the JVM subAllocator heap suggests that the JVM is causing the problem; corruption in the user-allocated memory suggests that user code is corrupting memory. Typically, user and JVM allocated memory are interleaved.

zero

Newly allocated blocks are set to 0 instead of being filled with the 0xE7E7xxxxxxxxE7E7 pattern. Setting these blocks to 0 helps you to determine whether a callsite is expecting zeroed memory, in which case the allocation request is followed by memset(pointer, 0, size).

Note: The -Xcheck:memory option cannot be used in the -Xoptionsfile.

Parent: -Xcheck

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.