概要

提供一種低開銷的Java堆分配采樣方式，可通過JVMTI訪問。

目標

提供一種從JVM獲取Java對象堆分配信息的方法:

• 開銷足夠低，可以在默認情況下連續(xù)啟用，
• 可以通過定義良好的編程接口訪問，
• 可以對所有的分配進行抽樣(即，不局限于一個特定堆區(qū)域中的分配或以一種特定方式分配的分配)，
• 可以以一種與實現(xiàn)無關(guān)的方式定義(即，不依賴于任何特定的GC算法或VM實現(xiàn))，以及
• 可以提供有關(guān)活的和死的Java對象的信息。

動機

用戶非常需要理解堆的內(nèi)容。糟糕的堆管理可能會導(dǎo)致堆耗盡和GC抖動等問題。因此，人們開發(fā)了許多工具來允許用戶自省他們的堆，例如Java Flight Recorder、jmap、YourKit和VisualVM工具。

大多數(shù)現(xiàn)有工具缺少的一個信息是特定分配的調(diào)用站點。堆轉(zhuǎn)儲和堆直方圖不包含此信息。此信息對于調(diào)試內(nèi)存問題非常重要，因為它告訴開發(fā)人員代碼中發(fā)生特定(特別糟糕的)分配的確切位置。

目前有兩種方法從熱點獲取這些信息:

• 首先，您可以使用字節(jié)碼重寫器(例如Allocation Instrumenter)來檢測應(yīng)用程序中的所有分配。然后，您可以讓插裝進行堆棧跟蹤(當(dāng)您需要時)。
• 其次，您可以使用Java Flight Recorder，它在TLAB重新填充和直接分配到老一代時進行堆棧跟蹤。這樣做的缺點是:a)它綁定到特定的分配實現(xiàn)(TLABs)，并且錯過了不符合該模式的分配;B)它不允許用戶自定義采樣間隔;c)它只記錄分配，所以你無法區(qū)分活對象和死對象。

該建議通過提供可擴展的JVMTI接口來緩解這些問題，該接口允許用戶定義采樣間隔并返回一組活動堆棧跟蹤。

描述

新的JVMTI事件和方法

這里提出的面向用戶的堆采樣特性API由JVMTI的擴展組成，該擴展允許進行堆分析。以下系統(tǒng)依賴于提供回調(diào)的事件通知系統(tǒng)，例如:

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

說明：

• thread是分配對象的線程
• object是對采樣對象的引用
• object_klass是jobject的類
• size是分配的大小

新的API還包括一個新的JVMTI方法:

jvmtiError  SetHeapSamplingInterval(jvmtiEnv* env, jint sampling_interval)

其中sampling_interval是兩次采樣之間分配的平均字節(jié)數(shù)。該方法的規(guī)格為:

• 如果不為零，采樣間隔將被更新，并將用sampling_interval字節(jié)的新平均采樣間隔發(fā)送回調(diào)給用戶

• 例如，如果用戶希望每兆字節(jié)采樣一次，則sampling_interval將是1024 * 1024。

• 如果將0傳遞給方法，采樣器在考慮到新的間隔后對每個分配進行采樣，這可能需要一定數(shù)量的分配

注意，采樣間隔是不精確的。每次出現(xiàn)一個樣本時，在下一個樣本被選擇之前的字節(jié)數(shù)將是給定平均間隔的偽隨機。這是為了避免抽樣偏差;例如，如果相同的分配每512KB發(fā)生一次，512KB采樣間隔將始終對相同的分配進行采樣。因此，雖然采樣間隔并不總是選擇的間隔，但在大量的樣本之后，它會趨向于它。

用例示例

要啟用此功能，用戶將使用通常的事件通知調(diào)用來操作:

jvmti->SetEventNotificationMode(jvmti, JVMTI_ENABLE, JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL)

該事件將在分配初始化并正確設(shè)置時發(fā)送，因此略晚于實際代碼執(zhí)行分配之后。缺省情況下，平均采樣間隔為512KB。

啟用采樣事件系統(tǒng)的最低要求是使用JVMTI_ENABLE和事件類型
JVMTI_EVENT_SAMPLED_OBJECT_ALLOC調(diào)用SetEventNotificationMode。要修改采樣間隔，用戶調(diào)用SetHeapSamplingInterval方法。

禁用方式，

jvmti->SetEventNotificationMode(jvmti, JVMTI_DISABLE, JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL)

禁用事件通知并自動禁用采樣器。

通過SetEventNotificationMode再次調(diào)用采樣器將使用當(dāng)前設(shè)置的采樣間隔重新啟用采樣器(默認為512KB或用戶通過SetHeapSamplingInterval傳遞的最后一個值)。

新功能

為了保護新特性并使其成為VM實現(xiàn)的可選特性，在jvmtiCapabilities中引入了名為
can_generate_sampled_object_alloc_events的新功能。

全局/線程級采樣

使用通知系統(tǒng)提供了一種僅為特定線程發(fā)送事件的直接方法。這是通過SetEventNotificationMode完成的，并提供第三個參數(shù)，其中包含要修改的線程。

完整的例子

下面的部分提供代碼片段來演示采樣器的API。首先，啟用功能和事件通知:

jvmtiEventCallbacks callbacks;
memset(&callbacks, 0, sizeof(callbacks));
callbacks.SampledObjectAlloc = &SampledObjectAlloc;

jvmtiCapabilities caps;
memset(&caps, 0, sizeof(caps));
caps.can_generate_sampled_object_alloc_events = 1;
if (JVMTI_ERROR_NONE != (*jvmti)->AddCapabilities(jvmti, &caps)) {
  return JNI_ERR;
}

if (JVMTI_ERROR_NONE != (*jvmti)->SetEventNotificationMode(jvmti, JVMTI_ENABLE,
                                       JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL)) {
  return JNI_ERR;
}

if (JVMTI_ERROR_NONE !=  (*jvmti)->SetEventCallbacks(jvmti, &callbacks, sizeof(jvmtiEventCallbacks)) {
  return JNI_ERR;
}

// Set the sampler to 1MB.
if (JVMTI_ERROR_NONE !=  (*jvmti)->SetHeapSamplingInterval(jvmti, 1024 * 1024)) {
  return JNI_ERR;
}

禁用采樣器(禁用事件和采樣器):

if (JVMTI_ERROR_NONE != (*jvmti)->SetEventNotificationMode(jvmti, JVMTI_DISABLE,
                                       JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL)) {
  return JNI_ERR;
}

要重新啟用1024 * 1024字節(jié)采樣間隔的采樣器，需要一個簡單的調(diào)用來啟用事件:

if (JVMTI_ERROR_NONE != (*jvmti)->SetEventNotificationMode(jvmti, JVMTI_ENABLE,
                                       JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL)) {
  return JNI_ERR;
}

抽樣分配的用戶存儲

當(dāng)事件生成時，回調(diào)可以使用JVMTI GetStackTrace方法捕獲堆棧跟蹤。回調(diào)獲得的jobject引用也可以包裝成JNI弱引用，以幫助確定對象何時已被垃圾收集。這種方法允許用戶收集關(guān)于采樣對象的數(shù)據(jù)，以及仍然被認為是活動的對象的數(shù)據(jù)，這是了解作業(yè)行為的好方法。

例如，可以這樣做:

extern "C" JNIEXPORT void JNICALL SampledObjectAlloc(jvmtiEnv *env,
                                                     JNIEnv* jni,
                                                     jthread thread,
                                                     jobject object,
                                                     jclass klass,
                                                     jlong size) {
  jvmtiFrameInfo frames[32];
  jint frame_count;
  jvmtiError err;

  err = global_jvmti->GetStackTrace(NULL, 0, 32, frames, &frame_count);
  if (err == JVMTI_ERROR_NONE && frame_count >= 1) {
    jweak ref = jni->NewWeakGlobalRef(object);
    internal_storage.add(jni, ref, size, thread, frames, frame_count);
  }
}

如果internal_storage是一個可以處理采樣對象的數(shù)據(jù)結(jié)構(gòu)，請考慮是否需要清理任何垃圾收集的樣本，等等。該實現(xiàn)的內(nèi)部是特定于使用的，超出了這個JEP的范圍。

采樣間隔可以用作減少分析開銷的一種手段。使用512KB的采樣間隔，開銷應(yīng)該足夠低，用戶可以合理地在默認情況下打開系統(tǒng)。

實現(xiàn)細節(jié)

目前的原型和實現(xiàn)證明了該方法的可行性。它包括五個部分:

1. 由于ThreadLocalAllocationBuffer (TLAB)結(jié)構(gòu)中字段名稱的更改，導(dǎo)致架構(gòu)相關(guān)的更改。這些更改是最小的，因為它們只是名稱更改。
2. TLAB結(jié)構(gòu)增加了一個新的allocation_end指針，以補充現(xiàn)有的結(jié)束指針。如果禁用采樣，則兩個指針始終相等，代碼將像以前一樣執(zhí)行。如果啟用了采樣，end將被修改為請求下一個采樣點的位置。然后，任何快速路徑都會“認為”TLAB在此時已經(jīng)滿了，然后沿著慢路徑走，這在(3)中解釋過。
3. gc/shared/collectedHeap代碼被更改，因為它被用作分配慢路徑的入口點。當(dāng)TLAB被認為已滿(因為分配已傳遞結(jié)束指針)時，代碼進入collectedHeap并嘗試分配一個新的TLAB。此時，TLAB將恢復(fù)到其原始大小，并嘗試進行分配。如果分配成功，代碼對分配進行采樣，然后返回。如果沒有，則意味著TLAB的分配已經(jīng)結(jié)束，需要一個新的TLAB。代碼路徑繼續(xù)其對新TLAB的正常分配，并確定該分配是否需要示例。如果分配被認為對TLAB來說太大，系統(tǒng)也會對分配進行抽樣，從而覆蓋TLAB分配內(nèi)和TLAB分配外進行抽樣。
4. 當(dāng)請求一個示例時，堆棧上有一個收集器對象設(shè)置在一個安全的位置，用于將信息發(fā)送到本機代理。收集器跟蹤采樣分配，并在銷毀自己的幀時向代理發(fā)送回調(diào)。該機制確保對象被正確初始化。
5. 如果JVMTI代理為SampledObjectAlloc事件注冊了回調(diào)，則該事件將被觸發(fā)，并且它將獲得抽樣分配。在libHeapMonitorTest.c文件中可以找到一個示例實現(xiàn)，該文件用于JTreg測試。

選擇

對于這個JEP中提出的系統(tǒng)，有多種替代方案。介紹中已經(jīng)介紹了兩個:Flight Recorder提供了一個有趣的替代方案。這個實現(xiàn)提供了幾個優(yōu)點。首先，JFR不允許設(shè)置抽樣大小或提供回調(diào)。其次，當(dāng)緩沖區(qū)耗盡時，JFR使用緩沖區(qū)系統(tǒng)可能導(dǎo)致分配丟失。最后，JFR事件系統(tǒng)沒有提供跟蹤已被垃圾收集的對象的方法，這意味著不可能使用它來提供有關(guān)活動對象和垃圾收集對象的信息。

另一種替代方法是使用ASM的字節(jié)碼插裝。它的開銷讓人望而卻步，不是一個可行的解決方案。

這個JEP向JVMTI添加了一個新特性，JVMTI是用于各種開發(fā)和監(jiān)視工具的重要API/框架。有了它，JVMTI代理可以使用低開銷的堆分析API以及其他JVMTI功能，這為工具提供了極大的靈活性。例如，由代理決定是否需要在每個事件點收集堆棧跟蹤。

測試

JTreg框架中針對該特性有16個測試:使用多個線程打開/關(guān)閉，同時分配多個線程，測試數(shù)據(jù)是否以正確的間隔采樣，以及收集的堆棧是否反映正確的程序信息。

風(fēng)險和假設(shè)

禁用該特性不會造成性能損失或風(fēng)險。沒有啟用系統(tǒng)的用戶不會感知到性能差異。

但是，啟用該特性會有潛在的性能/內(nèi)存損失。在最初的原型實現(xiàn)中，開銷是最小的(<2%)。這使用了一個更重量級的機制來修改JIT代碼。在這里給出的最終版本中，系統(tǒng)依賴于TLAB代碼，并且不應(yīng)該經(jīng)歷這種回歸。

目前對Dacapo基準測試的評估顯示開銷為:

• 禁用時為0%
• 1%，當(dāng)以默認的512KB間隔啟用該特性，但不執(zhí)行回調(diào)動作(即SampledAllocEvent方法為空，但已注冊到JVM)。
• 3%開銷，使用抽樣回調(diào)，執(zhí)行簡單的實現(xiàn)來存儲數(shù)據(jù)(使用測試中的實現(xiàn))