Java Tools (jmap,jstack) source code analysis on Linux (iv) Safe POINT__ data structure

Safe Point Gu Mingsi, that is, when the JVM needs to do some operations, the current running thread needs to enter a security point of the State (also can be said to stop state), so as to do some safe operation, such as the thread dump, stack information.

The usual vm_thread in the JVM (the threads we've been talking about doing things that belong to the VM) and Cms_thread (memory-recycled threads) are the need to put other threads through the call Safepointsynchronize::begin and Safepointsynchronize:end to enable other threads to enter or exit safe Point state. Usually, there are three states of SafePoint.

_not_synchronized	Indicates that there is no action to interrupt all threads running now, that is VM thread, and that CMS thread is not being instructed to do so
_synchronizing	VM THREAD,CMS thread to operational instruction, waiting for all threads to enter safe point
_synchronized	All threads Enter safe point, VM thread, CMS thread can start instruction operation

state of Java Threads

Java threads usually have several different states in Java processes, how to get these threads into the SafePoint state, the JVM is in a different way . Interpretation of Implementation

Since Java is an explanatory language, and threads need to dispatch table to log method addresses when interpreting Java bytecode, it is easier to get the thread into the stop state, as long as you replace dispatch table. Let the thread know that it is currently entering the Softpoint state.

Java will set up 3 dispatchtable, _active_table, _normal_table, _safept_table

_active_table is interpreting the dispatch table used by the running thread

_normal_table is the dispatch table that runs normally.

_safept_table Safe Point needs dispatch table

Explain the running thread has been using _active_table, the key is to enter the Saftpoint, with _safept_table replacement _active_table, in the exit Saftpoint, the use of _normal_ Table to replace _active_table

Specific implementation can view the source code

void Templateinterpreter::notice_safepoints () {
  if (!_notice_safepoints) {
    //switch to SafePoint Dispatch Table
    _notice_safepoints = true;
    Copy_table ((address*) &_safept_table, (address*) &_active_table, sizeof (_active_table)/sizeof (address);
  }
}

Switch from the dispatch table which notices safepoints back to the
/normal dispatch table.  So we can notice a single stepping points,
//Keep the safepoint dispatch table if we are single stepping in JVMTI.
//Note this should_post_single_step test is exactly as fast as the
//jvmtiexport::_enabled test and cover s both cases.
void Templateinterpreter::ignore_safepoints () {
  if (_notice_safepoints) {
    if (! Jvmtiexport::should_post_single_step ()) {
      //switch to normal dispatch table
      _notice_safepoints = false;
      Copy_table ((address*) &_normal_table, (address*) &_active_table, sizeof (_active_table)/sizeof (address);
    }
  }
}

B. Running in native code

If the thread is running in native code, VM thread does not need to wait for the thread to execute, just to judge the state of the _state when returning from the native code.

In the method body is the previous blog also appeared safepointsynchronize::d O_call_back ()

  inline static bool Do_call_back () {return
    (_state!= _not_synchronized);
  }

Judged _state not _not_synchronized state.

In order to allow a thread to go back to Java from native code in order to be able to read/set the correct thread state, the usual solution uses memory Barrier,java to use Orderaccess::fence (); Use __asm__ volatile in the assembly ("lock; Addl $0,0 (%%RSP) ":::" CC "," Memory "); Guaranteed to read the correct value from memory, but this method seriously affects the performance of the system, so Java uses each thread has a separate memory page to set the state. By using the memory barrier using the parameter-xx:+usemembar parameter, the default is not open, which is to use a separate memory page to set the state.