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.
I agree with you. It is just not very obvious that the system kernel holds some internal lock when a thread is executing VEH. 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
