Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of evgueni.brevnov@gmail.com
 designates 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=aezj35cuffXIdWb+6C1buhUczhWQBuLt5q5TRK39fl3ia5PuDjyf4371yYAk3j1zD3IZ8Z2iNKo6rCcHbuecXunRuFi6rZFuHLuI7R5jBhAcQbzxyzp/dovyNyTODVT/LAEnvo3+4gqaJVDREk6I71cZJt4m+T59mYhPGnNkdHk=
Message-ID: <e29119980611240741x6b353a05g2b9c6e3ae927498@mail.gmail.com>
Date: Fri, 24 Nov 2006 21:41:57 +0600
From: "Evgueni Brevnov" <evgueni.brevnov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][classlib unit tests] iterative runs
In-Reply-To: <ek72q1$t6q$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <678b3f320611210606w61cb787r157efd4ad941735d@mail.gmail.com>
	 <c30d70960611211602t640f94bbkb70a981cd5b79ce9@mail.gmail.com>
	 <200611240019.59711.gshimansky@gmail.com> <ek5k1t$ta8$1@sea.gmane.org>
	 <e29119980611232140n76ed82fdreff7954d413a70c3@mail.gmail.com>
	 <ek72q1$t6q$1@sea.gmane.org>

On 11/24/06, Salikh Zakirov <Salikh.Zakirov@intel.com> 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.
>
> 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.

Sounds reasonable :-)

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

Hmmm .... this is intresting.... Good catch!

Evgueni
>
>
>
>