GCLockerの遅いパスと高速パスは何ですか？

Question

1. HotSpot JVMのGCLocker for JNIクリティカルリージョンで、遅くて高速なパスは何ですか？

2. これら2つの概念の違いは何ですか？

class GCLockerからコードコメントが見つかりました。

// JNI critical regions are the only participants in this scheme 
    // because they are, by spec, well bounded while in a critical region. 
    // 
    // Each of the following two method is split into a fast path and a 
    // slow path. JNICritical_lock is only grabbed in the slow path. 
    // _needs_gc is initially false and every java thread will go 
    // through the fast path, which simply increments or decrements the 
    // current thread's critical count. When GC happens at a safepoint, 
    // GCLocker::is_active() is checked. Since there is no safepoint in 
    // the fast path of lock_critical() and unlock_critical(), there is 
    // no race condition between the fast path and GC. After _needs_gc 
    // is set at a safepoint, every thread will go through the slow path 
    // after the safepoint. Since after a safepoint, each of the 
    // following two methods is either entered from the method entry and 
    // falls into the slow path, or is resumed from the safepoints in 
    // the method, which only exist in the slow path. So when _needs_gc 
    // is set, the slow path is always taken, till _needs_gc is cleared. 
    static void lock_critical(JavaThread* thread); 
    static void unlock_critical(JavaThread* thread); 

Answer 1

答えは、あなたが引用してきた引用であるので、私はあなたが探している他に何かわかりません。

• 高速パスは、_needs_gc == falseの場合、単にカウンタを増減します - Thread::_jni_active_critical。
• 遅いパス_needs_gc == trueがグローバルロック（mutex）を通過するとき。ミューテックスは、最後のスレッドがクリティカル領域を離れるとGCが一度呼び出されるようにするために必要です。

ので、ちょうどgcLocker.inline.hppに実装を見て、あなたはすでにあなたの前にホットスポット源を持っているようだ：

inline void GC_locker::lock_critical(JavaThread* thread) { 
    if (!thread->in_critical()) { 
    if (needs_gc()) { 
     // jni_lock call calls enter_critical under the lock so that the 
     // global lock count and per thread count are in agreement. 
     jni_lock(thread); <-- SLOW PATH 
     return; 
    } 
    increment_debug_jni_lock_count(); 
    } 
    thread->enter_critical(); <-- FAST PATH 
} 

を、高速/低速のパスに分割するの背後にある考え方が入るようにすることです/去りますGCが要求されていない場合、できるだけ早くJNIクリティカル領域。 JNIメソッドは、GCが必要な場合にのみ、クリティカルセクションのオーバーヘッドに耐えます。