Profiler - Custom Profiling

Home > Profiling Tasks > Custom Profiling

Memory Profiling Settings

In the Custom Profiling mode, you have complete control over all of the internal profiling settings available. When you choose memory profiling, you can choose between recording only object creation or the entire object lifecycle (i.e. both creation and garbage collection).

Choosing the Memory Profiling option brings up the following settings dialog box:

Custom Memory Profiling Settings

The profiling can be custom tailored by the following options:

  • Stack sampling depth: full or limited. Every time Profiler records an object creation, it also records the call stack at this moment. This is a relatively expensive operation, thus the maximum depth of recorded stack, i.e. the number of frames from the top that are recorded (by default it is unlimited) is adjustable. Limiting the maximum depth to a small number, say 3..5, may reduce profiling overhead very substantially, up to making the application run several times faster for allocation-intensive applications.

  • Take stack sampling every... (stack sampling interval). As explained in the statistical memory data collection section, Profiler records object allocation, takes a stack sample, and subsequently tracks an object (in the Record the entire object lifecycle mode) not for all objects, but just up to a certain proportion of them. The above number specifies this proportion. Note, however, that the partial recording is only about stack sampling and tracking the object; the total number of object allocations is recorded separately, and no allocations are missing from it. If the stack sampling interval is set to, say, 10, it means that for each class only every 10th object allocation will be recorded completely. Set this number to 1 if you want to record all information for each object, but keep in mind that this may affect the profiling overhead very substantially for allocation-intensive applications. In reality, for server-side applications under real-life workload it may often make sense to set this number to 20 or more – this helps to minimise the overhead, and the amount of obtained information is still sufficient for practical purposes.

  • Run garbage collection when getting memory results. If this box is checked, full Garbage Collection is invoked in the target JVM every time you click Profile -> Get Current Results ( ). Running GC may help to obtain a more realistic picture of object liveness, since dead objects will be garbage collected and thus not reported as live. However, full GC may be expensive, especially for large applications (where it may take from several to several tens of seconds), so this option should be used with care.

See also


Project Features

About this Project

Profiler was started in November 2009, is owned by Tomas Hurka, and has 62 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm