Description
This is a follow-up suggestion for a resolution to the discussion about the conditional vs unconditional use of trace-related code in general.
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-May/023328.html
Quote:
" ... consider revisiting the conditional versus unconditional use of trace-related code in general.
So that things like:
EventClassLoad class_load_start_event;
post_class_load_event(&class_load_start_event, k, loader_data);
were done using TRACE_ONLY, so that all trace-related code was
completely excluded when not using INCLUDE_TRACE."
About the resolution:
This can be solved better with the introduction of a TRACE_ONLY macro, where the code decorated with this macro is conditionally inserted depending on the INCLUDE_TRACE define.
With this in place, we can also support several ways to better "move" the event tracing functionality from off the main logic for those contexts where less conditional code could improve readability for the overall logic.
The most common case is probably the declaration and definition before use (in .cpp)):
#if INCLUDE_TRACE
static void post_name_event(MyEvent* ev) {
...
ev.commit();
}
#endif
void myfunction() {
TRACE_ONLY(MyEvent ev;) // Conditionally defined event stack variable
...
...
TRACE_ONLY(post_name_event(&ev, ...);)
}
Further options:
Only forward declare the post function (to be defined after the function to be traced):
TRACE_ONLY(void post_name_event(Event* ev);) // fwd declare
void myfunction() {
TRACE_ONLY(MyEvent ev;)
...
TRACE_ONLY(post_name_event(&ev, ...);)
}
...
// definition
For even more flexibility, the trace functions can be moved to entirely separate code files:
// mytracefile.inline.hpp
#if INCLUDE_TRACE
inline void post_name_event_1(Event* ev) {
...
ev.commit();
}
inline void post_name_event_2(Event* ev) {
...
ev.commit();
}
...
#endif
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-May/023328.html
Quote:
" ... consider revisiting the conditional versus unconditional use of trace-related code in general.
So that things like:
EventClassLoad class_load_start_event;
post_class_load_event(&class_load_start_event, k, loader_data);
were done using TRACE_ONLY, so that all trace-related code was
completely excluded when not using INCLUDE_TRACE."
About the resolution:
This can be solved better with the introduction of a TRACE_ONLY macro, where the code decorated with this macro is conditionally inserted depending on the INCLUDE_TRACE define.
With this in place, we can also support several ways to better "move" the event tracing functionality from off the main logic for those contexts where less conditional code could improve readability for the overall logic.
The most common case is probably the declaration and definition before use (in .cpp)):
#if INCLUDE_TRACE
static void post_name_event(MyEvent* ev) {
...
ev.commit();
}
#endif
void myfunction() {
TRACE_ONLY(MyEvent ev;) // Conditionally defined event stack variable
...
...
TRACE_ONLY(post_name_event(&ev, ...);)
}
Further options:
Only forward declare the post function (to be defined after the function to be traced):
TRACE_ONLY(void post_name_event(Event* ev);) // fwd declare
void myfunction() {
TRACE_ONLY(MyEvent ev;)
...
TRACE_ONLY(post_name_event(&ev, ...);)
}
...
// definition
For even more flexibility, the trace functions can be moved to entirely separate code files:
// mytracefile.inline.hpp
#if INCLUDE_TRACE
inline void post_name_event_1(Event* ev) {
...
ev.commit();
}
inline void post_name_event_2(Event* ev) {
...
ev.commit();
}
...
#endif