On 11/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Saturday 25 November 2006 15:23 Evgueni Brevnov wrote: > > > A1) segfault occured > > > A2) grab "system hwe lock" and call vectored_exception_handler > > > A3) instantiate NullPointerException object > > > A4) set up throwing NullPointerExceptionObject in the register snapshot > > > A5) return from vectored_exception_handler release "system hwe lock" > > > > > > Let's next assume that garbage collection was started exactly when > > > thread A was in progress of running NullPointerException constructor. > > > Then, thread A will be suspended while still holding "system hwe lock". > > I see two bad things here. The first one is a violation of the pretty > known "rule". The rule is don't execute java methods under native > lock. That was discussed several times already. Another problem is > that two threads contend for the one lock while being in different > modes. In other words the first thread gets the lock in suspend > enabled state. The second thread tries to get the same lock in suspend > disabled state. But the first thread is already suspended by GC what > causes a deadlock. Thus it seems like another "rule" for me. > > Any native lock MUST be used either in suspend disabled or suspend > enabled regions. It is prohibited to go outside of the region with the > owned lock.
The above seems to make sense. It might be possible to to add asserts to verify the rule is not violated. I agree with you. It is just not very obvious that the system kernel holds
some internal lock when a thread is executing VEH.
hmm.... this conversation seems to be mixing DRLVM native code locks with locks that are internal to the underlying OS (or OS provided user-level libraries). Its important to sort out both issues. Gregory, can you clarify? It is windows specific and
specific only to some windows versions. We know for sure that windows 2003 server SP1 doesn't have this problem.
I am not sure if it is documented anywhere. We've found the fact that this
lock exists in a hard way. > Does the above make sense? Could we somehow ensure this rule with > assert statements? Yes it does. I've always wanted to have a function of Lock_Manager, something like bool is_locked_by_this_thread(). But asserts may be used only on the lock which are controlled by VM. Internal kernel or C runtime locks cannot be checked easily. -- Gregory
-- Weldon Washburn Intel Enterprise Solutions Software Division
