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:
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 -> Run GC
( 
).
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
