Summary

This item is about the initial integration of the Heap Sampling into the JDK. The usage of the system is done via a JVMTI event and a method to set the sampling rate. The system provides insight on heap allocations leveraging with a very low overhead.

Problem

There is no real low overhead sampling mechanism for heap allocations, which provides stacktraces and enables users to understand memory allocations in a detailed way but also be able to turn on/off the system during execution and determine which threads to track.

Solution

The system is defined by JEP-331. The system adds a piggy back on TLAB refills to call to be captured by an event collector and sent if requested to a user.

An email thread is here explaining in more detail the solution: https://marc.info/?l=openjdk-serviceability-dev&m=148166356005563&w=2

Specification

JVMTI Specification is changed by adding a new event:

void JNICALL
SampledObjectAlloc(jvmtiEnv *jvmti_env,
        JNIEnv* jni_env,
        jthread thread,
        jobject object,
        jclass object_klass,
        jlong size)

To enable this, a user would use the usual call to:

 SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL);

By default, the sampling rate is set at 512kb, meaning there will be in average one event for every 512k bytes allocated. To change the sampling rate, see below the description of the SetHeapSamplingRate method.

To disable, a user would use the call to disable sampling and turn off the notifications:

 SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL);

This event uses a new capability: can_generate_sampled_object_alloc_events.

There is also the addition of a new method to the JVMTI. In the case a user wants a different sampling rate than the default sampling rate of 512kb, the user can call:

jvmtiError  SetHeapSamplingRate(jvmtiEnv* env, jint monitoring_rate)

• SetHeapSamplingRate: this provides the sampling rate in bytes for the allocations, the method takes an integer sampling_rate, which represents:
  • If non zero, the sampling rate is updated and will send a callback to the user with the new average sampling rate of sampling_rate bytes
    • For example, if the user wants a sample every megabyte, sampling_rate would be 1024 * 1024.
  • If zero is passed to the method, every allocation is sampled

Notes:

• If a user does not call this, the default sampling rate is 512kb.
• This method can be called before/after event enabling/disabling, the latest value passed will be stored for whenever enabling the SampledObjectAlloc event occurs in the future.
• This method uses a new capability: can_generate_sampled_object_alloc_events.
• It will fail if the monitoring rate is negative
• Sampling rate provided to the methods is in bytes

More information can be found directly with the webrev: http://cr.openjdk.java.net/~jmanson/8171119/webrev.00/

The JVMTI Spec additions are provided in attachment to this issue: https://bugs.openjdk.java.net/secure/attachment/77002/jvmti.diff.html