21 * or visit www.oracle.com if you need additional information or have any
22 * questions.
23 *
24 */
25
26 #include "precompiled.hpp"
27 #include "code/codeHeapState.hpp"
28 #include "compiler/compileBroker.hpp"
29 #include "runtime/sweeper.hpp"
30
31 // -------------------------
32 // | General Description |
33 // -------------------------
34 // The CodeHeap state analytics are divided in two parts.
35 // The first part examines the entire CodeHeap and aggregates all
36 // information that is believed useful/important.
37 //
38 // Aggregation condenses the information of a piece of the CodeHeap
39 // (4096 bytes by default) into an analysis granule. These granules
40 // contain enough detail to gain initial insight while keeping the
41 // internal sttructure sizes in check.
42 //
43 // The CodeHeap is a living thing. Therefore, the aggregate is collected
44 // under the CodeCache_lock. The subsequent print steps are only locked
45 // against concurrent aggregations. That keeps the impact on
46 // "normal operation" (JIT compiler and sweeper activity) to a minimum.
47 //
48 // The second part, which consists of several, independent steps,
49 // prints the previously collected information with emphasis on
50 // various aspects.
51 //
52 // Data collection and printing is done on an "on request" basis.
53 // While no request is being processed, there is no impact on performance.
54 // The CodeHeap state analytics do have some memory footprint.
55 // The "aggregate" step allocates some data structures to hold the aggregated
56 // information for later output. These data structures live until they are
57 // explicitly discarded (function "discard") or until the VM terminates.
58 // There is one exception: the function "all" does not leave any data
59 // structures allocated.
60 //
61 // Requests for real-time, on-the-fly analysis can be issued via
62 // jcmd <pid> Compiler.CodeHeap_Analytics [<function>] [<granularity>]
63 //
64 // If you are (only) interested in how the CodeHeap looks like after running
65 // a sample workload, you can use the command line option
66 // -Xlog:codecache=Trace
67 //
68 // To see the CodeHeap state in case of a "CodeCache full" condition, start the
69 // VM with the
70 // -Xlog:codecache=Debug
71 // command line option. It will produce output only for the first time the
72 // condition is recognized.
73 //
74 // Both command line option variants produce output identical to the jcmd function
75 // jcmd <pid> Compiler.CodeHeap_Analytics all 4096
76 // ---------------------------------------------------------------------------------
77
78 // With this declaration macro, it is possible to switch between
79 // - direct output into an argument-passed outputStream and
80 // - buffered output into a bufferedStream with subsequent flush
81 // of the filled buffer to the outputStream.
82 #define USE_STRINGSTREAM
83 #define HEX32_FORMAT "0x%x" // just a helper format string used below multiple times
84 //
85 // Writing to a bufferedStream buffer first has a significant advantage:
86 // It uses noticeably less cpu cycles and reduces (when wirting to a
87 // network file) the required bandwidth by at least a factor of ten.
88 // That clearly makes up for the increased code complexity.
89 #if defined(USE_STRINGSTREAM)
90 #define STRINGSTREAM_DECL(_anyst, _outst) \
91 /* _anyst name of the stream as used in the code */ \
92 /* _outst stream where final output will go to */ \
93 ResourceMark rm; \
94 bufferedStream _sstobj(4*K); \
|
21 * or visit www.oracle.com if you need additional information or have any
22 * questions.
23 *
24 */
25
26 #include "precompiled.hpp"
27 #include "code/codeHeapState.hpp"
28 #include "compiler/compileBroker.hpp"
29 #include "runtime/sweeper.hpp"
30
31 // -------------------------
32 // | General Description |
33 // -------------------------
34 // The CodeHeap state analytics are divided in two parts.
35 // The first part examines the entire CodeHeap and aggregates all
36 // information that is believed useful/important.
37 //
38 // Aggregation condenses the information of a piece of the CodeHeap
39 // (4096 bytes by default) into an analysis granule. These granules
40 // contain enough detail to gain initial insight while keeping the
41 // internal structure sizes in check.
42 //
43 // The CodeHeap is a living thing. Therefore, the aggregate is collected
44 // under the CodeCache_lock. The subsequent print steps are only locked
45 // against concurrent aggregations. That keeps the impact on
46 // "normal operation" (JIT compiler and sweeper activity) to a minimum.
47 //
48 // The second part, which consists of several, independent steps,
49 // prints the previously collected information with emphasis on
50 // various aspects.
51 //
52 // Data collection and printing is done on an "on request" basis.
53 // While no request is being processed, there is no impact on performance.
54 // The CodeHeap state analytics do have some memory footprint.
55 // The "aggregate" step allocates some data structures to hold the aggregated
56 // information for later output. These data structures live until they are
57 // explicitly discarded (function "discard") or until the VM terminates.
58 // There is one exception: the function "all" does not leave any data
59 // structures allocated.
60 //
61 // Requests for real-time, on-the-fly analysis can be issued via
62 // jcmd <pid> Compiler.CodeHeap_Analytics [<function>] [<granularity>]
63 //
64 // If you are (only) interested in how the CodeHeap looks like after running
65 // a sample workload, you can use the command line option
66 // -XX:+PrintCodeHeapAnalytics
67 // It will cause a full analysis to be written to tty. In addition, a full
68 // analysis will be written the first time a "CodeCache full" condition is
69 // detected.
70 //
71 // The command line option produces output identical to the jcmd function
72 // jcmd <pid> Compiler.CodeHeap_Analytics all 4096
73 // ---------------------------------------------------------------------------------
74
75 // With this declaration macro, it is possible to switch between
76 // - direct output into an argument-passed outputStream and
77 // - buffered output into a bufferedStream with subsequent flush
78 // of the filled buffer to the outputStream.
79 #define USE_STRINGSTREAM
80 #define HEX32_FORMAT "0x%x" // just a helper format string used below multiple times
81 //
82 // Writing to a bufferedStream buffer first has a significant advantage:
83 // It uses noticeably less cpu cycles and reduces (when wirting to a
84 // network file) the required bandwidth by at least a factor of ten.
85 // That clearly makes up for the increased code complexity.
86 #if defined(USE_STRINGSTREAM)
87 #define STRINGSTREAM_DECL(_anyst, _outst) \
88 /* _anyst name of the stream as used in the code */ \
89 /* _outst stream where final output will go to */ \
90 ResourceMark rm; \
91 bufferedStream _sstobj(4*K); \
|