xref: /netbsd-src/external/cddl/dtracetoolkit/dist/Docs/Notes/ALLjava_notes.txt (revision c29d51755812ace2e87aeefdb06cb2b4dac7087a)
1*c29d5175Schristos**************************************************************************
2*c29d5175Schristos* Notes for all scripts that trace Java using the hotspot provider.
3*c29d5175Schristos*
4*c29d5175Schristos* $Id: ALLjava_notes.txt,v 1.1.1.1 2015/09/30 22:01:08 christos Exp $
5*c29d5175Schristos*
6*c29d5175Schristos* COPYRIGHT: Copyright (c) 2007 Brendan Gregg.
7*c29d5175Schristos**************************************************************************
8*c29d5175Schristos
9*c29d5175Schristos* I see "drops"
10*c29d5175Schristos
11*c29d5175SchristosIf you see the following output,
12*c29d5175Schristos
13*c29d5175Schristos   dtrace: 2547 drops on CPU 0
14*c29d5175Schristos
15*c29d5175SchristosThis means that JVM events (usually methods) were executed too quickly for
16*c29d5175SchristosDTrace to keep up, and as a safety measure DTrace has let events slip by.
17*c29d5175SchristosThis means, at least, that the output is missing lines. At worst, the
18*c29d5175Schristosoutput may contain corrupted values (time deltas between events that were
19*c29d5175Schristosdropped).
20*c29d5175Schristos
21*c29d5175SchristosIf you see drops, you should first ask yourself whether you need to be
22*c29d5175Schristostracing such frequent events at all - is there another way to get the same
23*c29d5175Schristosdata?  For example, see the j_profile.d script, which uses a different
24*c29d5175Schristostechnique (sampling) than most of the other Java scripts (tracing).
25*c29d5175Schristos
26*c29d5175SchristosYou can try tweaking DTrace tunables to prevent DTrace from dropping events.
27*c29d5175SchristosA key tunable is "bufsize", and can be set in scripts like so,
28*c29d5175Schristos
29*c29d5175Schristos   #pragma D option bufsize=32m
30*c29d5175Schristos
31*c29d5175SchristosThat line means that 32 Mbytes will be allocated to the DTrace primary
32*c29d5175Schristosbuffer per-CPU (how depends on bufpolicy). If you have many CPUs, say 8,
33*c29d5175Schristosthen the above line means that 256 Mbytes (32 * 8) will be allocated as a
34*c29d5175Schristosbuffer while your D script is running.
35*c29d5175Schristos
36