harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][classlib unit tests] iterative runs
Date Sat, 25 Nov 2006 13:25:36 GMT
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.


View raw message