harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][classlib unit tests] iterative runs
Date Mon, 27 Nov 2006 15:03:25 GMT
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?


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message