Pekka Enberg wrote: > OK, assuming that we can send a signal to a thread that is either running or > blocked in native code with pthread_kill(), I think we can do something like > the following. > > The GC root set consists of references in: > > - Class variables > > - Native stack frame of all threads > > - Native registers of all threads > > A thread can be in one of the following states: > > - Running JIT'd code > > - Running native code > > - Blocked in JIT'd code (object monitor) > > - Blocked in native code (pthread_mutex_lock(), etc.) > > Finding root set references when a thread is running in native code or is > blocked is the most difficult part because when we're running in JIT'd code, > we can simply wait for the thread to enter a safepoint and we're done. This > will happen automatically as the thread polls the guard page at method > invocation or backward branch. > > As for the case of a thread running in native code, we know that there has > been a transition from JIT code to native code through a call-site which > always has a GC map attached to it. As all references that are visible to the > native code are either class variables or have been passed as function > arguments (and are part of a GC map), we can detect them.
I'm not sure what are you trying to say here. When there is a transition from JIT to native code all live caller saved registers are spilled, so their content is on stack. But callee saved registers are not spilled, so we can not assume that references which are in callee saved registers are enywhere on stack. The calle may or may not spill them, depending on whether they are scratched or not. So unless we force callee saved registers spilling at call sites, we are unable to retrieve those references later, when a thread is interrupted by the signal. Or have I misunderstood something? > Furthermore, as > native code is only allowed to create new instances through the JNI API, we > can track the new references separately and include them in the root set. > Therefore, we can simply interrupt the thread running in native code with a > signal using pthread_kill() that forces the thread to enter a safepoint. > > Blocking in JIT'd code is identical to blocking in native code because the JIT > compiler generates VM native calls for the _monitorenter_ and _monitorexit_ > bytecodes and rest of the blocking methods are also implemented as VM native > functions. Fortunately, we can consider the blocked in native code case to be > identical to the running in native code case and rely on the fact that we > entered the native code through a call-site that has a GC map. If we also > force the blocked thread to enter a safepoint through a signal, we can make > sure the thread does not wake up spuriously while it's supposed to be in the > safepoint. I think your idea is good, so to sum up my thoughts about it: When stop the world process is started we send signals to all threads but the GC thread, and the signal handler will do the checks, and either block in safepoint immediately or let the thread go until it reaches a consistent state. I think the policy should be as follows: 1) let the thread go to reach a safepoint when: - executing JIT code - executing VM code 2) enter safepoint immediately - blocked (but: is the VM state consistent from GC point of view on every mutex lock?) - executing JNI code We must add safepoints to VM <-> native transitions to avoid the situation when a thread is leaving the VM and then blocks in JNI on some mutex, causing stop-the-world to be stalled. To be able to enter safepoint immediately from the signal handler (cases 2), we must assure, that all registers containing references are spilled before JIT->native transition on stack. Tomek ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Jatovm-devel mailing list Jatovm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jatovm-devel
