なぜJNIアクティブインスタンスはGCを防止しますか？

Question

ブールPSScavenge :: invoke_no_policy（）

... 
    if (GCLocker::check_active_before_gc()) { 
    return false; 
    } 
    ... 

あなたが見ることができるようにGCLocker::check_active_before_gc()がtrueであれば、それはPSScavenge::invoke_no_policy()ある、マイナーGCを起動しません。それはなぜです？

check_active_before_gc（）

bool GCLocker::check_active_before_gc() { 
    assert(SafepointSynchronize::is_at_safepoint(), "only read at safepoint"); 
    if (is_active() && !_needs_gc) { 
    verify_critical_count(); 
    _needs_gc = true; 
    log_debug_jni("Setting _needs_gc."); 
    } 
    return is_active(); 
} 

is_active（）

// Accessors 
    static bool is_active() { 
    assert(SafepointSynchronize::is_at_safepoint(), "only read at safepoint"); 
    return is_active_internal(); 
    } 

is_active_internal（）

static bool is_active_internal() { 
    verify_critical_count(); 
    return _jni_lock_count > 0; 
    } 

_jni_lock_count

static volatile jint _jni_lock_count; // number of jni active instances. 

_jni_lock_countは、現在重要な領域にある であるスレッドの数を追跡します。

Answer 1

_jni_lock_countは、現在クリティカル領域にあるスレッドの数を記録します。

suggested by JNI specificationとして、JNIの重要な機能はガーベジコレクションを一時的に無効にします。それは ReleasePrimitiveArrayCriticalを呼び出す前にGetPrimitiveArrayCritical、長時間のためのネイティブコードすべきではない 実行を呼び出した後

。このペアの中のコード を「重要な領域」で実行しているものとして扱う必要があります。 の中で、ネイティブコードは他のJNI関数を呼び出さないでください。または、現在のスレッドをブロックして別の Javaスレッドを待つかもしれないシステム 呼び出しを呼び出さないでください。場合でも、これらの制限は、ネイティブコードが 配列のコピーされていないバージョンを取得する可能性を高めます

（例えば、現在のスレッドは、ほかのJavaスレッドが記述されている ストリームに読みを。呼び出してはいけません） VMには サポートピンがありません。たとえば、VMは、ネイティブコードがGetPrimitiveArrayCriticalで取得した配列 へのポインタを保持しているときに、 コレクションの一時的なガベージを無効にすることがあります。