harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][classlib unit tests] iterative runs
Date Tue, 28 Nov 2006 05:23:39 GMT
On 11/28/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Weldon Washburn wrote:
> > On 11/25/06, Gregory Shimansky <gshimansky@gmail.com> 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.

Seems like we mixing two diffrerent topics in one thread. Here is
another thread "[drlvm][threading] Native locks and thread suspension"
for discussing different deadlock scenarios...

Evgueni


>
> > 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
>
>

Mime
View raw message