Re: [Sablevm-developer] Question about _svmf_stopping_java()
Brought to you by:
egagnon
From: Archie C. <ar...@de...> - 2004-01-18 21:34:42
|
Etienne Gagnon wrote: > > However, I don't think this really gives you much advantage. It lets > > a thread continue in native mode instead of halting, but it probably > > is not going to get much further before having to come back to java mode > > and then halt anyway. Just a thought experiment really. > > Theoretically, it could quite possibly work (I would have to think carefully > about all corner cases, but there's no deep reason it wouldn't work), but > practically, I don't see much benefit. Current code simply depends on > the well tested _svmf_halt_if_requested(). Adding custom code for such critical > and difficult to write correctly code (even though it is short, it is very > tricky) is not something I look forward to. :-) I hear you :-) Simplicity is sometimes it's own reward.. The way I see it, if a thread is running in native mode then it is (by design) not allowed to directly touch any VM state, period, with a few exceptions (e.g., a thread in Object.wait() that needs to touch a fat lock). In those exception cases, the state it's touching is protected by a special mutex (e.g., the fat lock mutex). So as long as those exceptions are properly handled, then as far as the VM is concerned a thread running in native mode is equivalent to a halted thread. In either case, the VM state cannot be modified by the thread (which is why we try to halt them in the first place). But you would have to handle the exception cases. Using the fat lock example, if you had other native threads running during GC then the GC thread would have lock each thread's wait list mutex before changing the object pointers in the list (after moving the pointed-to object). So the tradeoff would be a questionable performance increse for an increase in complexity and race condition potential.. definitely not worth it. -Archie __________________________________________________________________________ Archie Cobbs * Halloo Communications * http://www.halloo.com |