Foreword
Multi-threaded programming is a difficult thing, or that the code is difficult to write a good run in multithreaded conditions. java provides synchronized and volatile keywords, as well as Lock and Atomic Classes related to the right to help us achieve concurrent logic, but I still tend to try to avoid concurrency in practice, there is a lazy approach is the need concurrent access plus volatile variables are always modified.
Recently encountered an example of two concurrent related, one is lock-free use logic AtomicInteger class prepared to achieve a colleague appeared bug, because the boundary condition is not treated well, lead to the emergence of an infinite loop; the other is a service As usual load is relatively high, there is a problem biased locking revocation takes too long.
Biased locking revoked
Biased locking jvm is actually an optimization of the lock, a lock for it assumes, in fact, only one thread is trying to access. Biased locking achieve is very simple, that is, when one thread to access the lock, this lock holder directly labeled this thread, when the thread tries to acquire the lock again, only need to check mark to the holders. Biased locking optimizations in the actual scene no more threads can compete effectively improve the performance of the program, but when the "no multi-threading competition" this assumption does not hold, biased locking requires additional logic revoked, and this is likely to be withdrawn bring pause, a long-time influence the performance of the program.
Why is biased locking revocation may cause long pause it, because the biased locking revocation actually need to be in the safe point. Biased locking revocation needs to be suspended thread holds the lock and operate its stack, so the need for the safe point. The time required to program into the safety point is uncertain, just like the concrete realization of the specific reasons related to the safety point.
safepoint
Safety point (hereinafter referred to as safepoint) is an important concept in the jvm, jvm will encounter many of the scenes in it, it should be the most common GC (although I mentioned earlier is biased locking revoked). Program safepoint meaning representation in certain fixed positions, these positions in the program status is "OK", then jvm can be performed according to the special operating state of the program, such as:
- gc: you need to clean out the object is no longer viable gc time, so it is necessary "OK" to know which object is no longer alive. Type (or reference value) gc will also be required to scan each thread's stack, so it is necessary "OK" until the stack of each object.
- Biased locking revoked: This mentioned earlier, because of the need to suspend the thread while operating the thread's stack.
- Update OopMap: oop (ordinary object pointer) is a data structure of the metadata for recording hotspot virtual machine objects, which records the type of the object corresponding to respective offset data. OopMap mainly used to achieve accurate formula GC, GC on the introduction of formula may be accurate reference herein
- Code deoptimization/Flushing code cache/Class redefinition/Various debug operation：来自这里
safepoint location
Jvm in the management of the operation, using the safepoint to suspend the entire program (Stop the World), and some special operations. The safepoint idea is simple: when we need to perform some special operations (such as gc), we set some point pause in some point in the program, when the thread to suspend these points, it will hang himself. Once all threads are suspended, then we scheduled a special operation. The safepoint specific location usually are the following:
- After each byte code command (interpreted mode)
- All methods before returning (JIT mode)
- All non-counting loop end (JIT mode)
Provided only at the end of the non-counting loop safepoint raises the question: If there is a very large program of cycle counts (such as cycle times 100w), it could lead safepoint time to hang the whole process becomes longer, because the other has been suspended the thread will need to wait for the big loop execution ends.
The aforementioned safepoint setting causes all threads hang, then specific gc biased locking or revoked in turn, the answer is, who is going to execute the VM thread. In the output of the jstack you can see there is a "VMThread" thread is called, this thread is responsible for handling all kinds of special operations at the time STW.
safe region
safepoint allows the running thread hangs the initiative, and the thread in the other states (such as sleep or are being blocked in a locked) you can not take the initiative to run safepoint. In this case jvm set in the safe area concept (safe region), and when the thread for some states, in this case jvm think this thread will not make any changes to the jvm heap, it will not destroy the jvm "OK," the state, these threads can be considered safe (in a safe zone). When a thread from the security zone in the security zone out, also need to check whether it should take the initiative to hang. jvm set in the following states of the thread is in safe region:
- In blocking or waiting
- JNI method being implemented
So when the thread is more than a few states, and we believe they will reach safepoint like, you can perform a special operation. In order to prevent the thread changes to the jvm heap from the safe region returns, the thread will take the initiative to hang when returning from a safe region when STW.
Thread suspended implementation
By setting safepoint in a particular location, we can let the program hangs when needed. When you need to STW, the safepoint will be activated when each thread runs to safepoint, will take the initiative to check the status safepoint if safepoint is activated, the thread will enter a suspended state. In simple terms, a thread when checking safepoint will take the initiative to access a specific memory page, and when STW this memory page as unreadable, so each attempt to read this memory page thread also will be suspended . This inspection process is active and inserted into the instruction by the JIT compiler.
And specifically, when the thread is in a different state, hung threads and there are also different:
- When the thread is interpreted, the interpreter will force the next instruction the instruction points to a check of the safepoint
- When the thread is executing JNI method, VMThread not wait for it to return, but that it is in a safe region. When it returns will be blocked until the end of STW
- When the thread is being executed has been compiled method, the compiled code will carry the logic checks safepoint, we will set specific memory page can be unreadable
- When the thread is blocked, VMThread not wait for his return, but that it is in a safe region. When it returns will be blocked until the end of STW
When a thread tries to access memory pages marked as unreadable, it will trigger SIGSEGV signal, thereby triggering the signal handler within the jvm, signal handler when it receives SIGSEGV signal confirms that the examination is due to safepoint trigger this signal, if it will will hang itself.
other
Many content reference iter_zc the blog , to express my gratitude.