Dnia 2009-12-07, pon o godzinie 20:01 +0100, Tomasz Grabiec pisze: > 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
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Jatovm-devel mailing list Jatovm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jatovm-devel
