GCLocker의 느리고 빠른 경로는 무엇입니까?

Question

1. HotSpot JVM의 GCLocker for JNI 중요 영역에서 느리고 빠른 경로는 무엇입니까?

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이 전역 잠금 (뮤텍스)을 통과 할 때. 뮤텍스는 마지막 스레드가 중요한 영역을 떠난 후에 GC가 한 번 호출되는지 확인하는 데 필요합니다./빠른/느린 경로로 분할 뒤에 아이디어는 입주를 만들기 위해

  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 
  } 
  

  입니다

  떠나 :

이미 그래서 그냥 gcLocker.inline.hpp의 구현을 살펴보고, 당신의 앞에 핫스팟 소스가 보인다 GC가 요청되지 않을 때 최대한 빨리 JNI 중요 영역. JNI 방법은 GC가 필요할 때만 임계 섹션의 오버 헤드를 견뎌냅니다.