The need for dynamically enabling and disabling profiling events requires added checks in the code paths that lead to the generation of these events.
Majority of profiling events are issued relatively infrequently. Examples of these types of events are class loading and unloading, thread start and end, garbage collection, and JNI global reference creation and deletion. We can easily support interactive low-overhead profiling by placing checks in the corresponding code paths without having a performance impact in normal program execution.
Heap profiling events, in particular NEW_OBJECT, DELETE_OBJECT, and MOVE_OBJECT introduced in Section 4.2, could be quite frequent. An added check in every object allocation may have a noticeable performance impact in program execution, especially if the check is inserted in the allocation fast path that typically is inlined into the code generated by the Just-In-Time (JIT) compilers. Fortunately, garbage-collected memory systems by definition need to check for possible heap exhaustion conditions in every object allocation, even in the fast path. We can thus enable heap allocation events by forcing every object allocation into the slow path with a false heap exhaustion condition, and check whether heap profiling events have been enabled and whether the heap is really exhausted in the slow path. Because no change to the allocation fast path is needed, object allocation runs in full speed when heap profiling is disabled.
Method enter and exit events are another kind of events that may be generated frequently. They can be easily supported by the JIT compilers that can dynamically patch the generated code and the virtual method dispatch tables.