Weldon Washburn wrote:
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?
I didn't think I was mixing these locks. The deadlock which made us
change VEH handler code occurred as a deadlock between kernel internal
lock, and VM lock. Even if we create a facility which would allow to
check (via assertion) the locked/unlocked state of VM locks, it won't
help us when there are locks which we don't control, like in this case.
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
