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 Sat, 25 Nov 2006 12:23:14 GMT
On 11/24/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Salikh Zakirov wrote:
> > Evgueni Brevnov wrote:
> >> Agree! It seems like a mess for me as well. The most clean approach is
> >> to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
> >> native code.
> >
> > I recently found out the reason why smoke test gc.LOS hangs DRLVM on Windows
> > XP, and it turned out to be related to the hardware exception handling.
> I can't believe we'll see this test running again :)
> > Since the fix will involve significant modifications to the file
> > vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp,
> > I can do this modification too.
> Good.
> > P.S. The reason of hang of gc.LOS is deadlock on a thread suspension:
> > Assume thread A handles NPE:
> >
> > 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.

Does the above make sense? Could we somehow ensure this rule with
assert statements?

> >
> > Another thread B at that moment may be blocked on a "system hwe lock",
> > and since this lock is system and not known to Thread Manager, it just
> > waits forever for thread B to reach a safepoint.
> This explains why this test doesn't hang on windows 2003 server SP1
> (without SP1 the test hangs). I've seen this problem with system locking
> some internal lock for VEH, and the fix for JVMTI is in HARMONY-1541.
> Probably all parts of exception/signal handling should be changed to
> this same trick - exit kernel to release the lock, and set EIP in
> register context to point to the real VM exceptions handler.
> --
> Gregory

View raw message