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.
- Hide quoted text -
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
