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 ivan.g.popov@gmail.com
 designates 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=mboq53ByHDUTPCqk5BPGPEmRQIdSmKn10kQ4ehGZRUQ9Bqocra2CxRVP64PXFyAuI6G41HBxA5a/UpqRoGCPW1T7tJD+D05fRXl1/UfLUlNcrjWvPwMCcOsUx6n30tcCkc0F//4R36j/73UZ8bOe6XBCJC3TThNeVAg3Uw+Ae8k=
Message-ID: <b6cb498e0703230941r8d4b286kdc5687b3d5a73f8d@mail.gmail.com>
Date: Fri, 23 Mar 2007 22:41:35 +0600
From: "Ivan Popov" <ivan.g.popov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][jni] NewGlobalRef() returns NULL for pending exception
 object
In-Reply-To: <eu0un7$8bb$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: <b6cb498e0703230901i28180bdft1e698283fc318493@mail.gmail.com>
	 <eu0un7$8bb$1@sea.gmane.org>

Gregory,

Since ExceptionClear() zeroes reference to exception object, it may be
collected before subsequent call to NewGlobalRef() can pin it. The
only safe way to prevent exception from garbage collection and be able
to report it to debugger is to call NewGlobalRef() before
ExceptionClear(). I cannot find any other solution.

Though this does not follow well JNI spec (which is quite vague in
many points), it works with RI. And I'd like NewGlobalRef() to be
fixed and don't return NULL in this case. Do you agree?

Thanks.
Ivan

On 3/23/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Ivan Popov wrote:
> > Working on HARMONY-3304 [1] I noticed problem with JNI function
> > NewGlobalRef() in DRLVM. If it is called for a pending exception
> > object before ExceptionClear() is invoked, it returns NULL, which is
> > interpreted as out of memory according to JNI spec [2]. This causes
> > errors in debug support. In Sun/BEA VM non-NULL reference is returned
> > in this case.
>
> Actually JNI specification [1] states that only 3 JNI functions may be
> safely called in exception state. Looking at the code of NewGloabRef I
> see that the check for exception was added at revision 489694 as a
> result of committing HARMONY-2817.
>
> > Simple workaround is to call ExceptionClear() before NewGlobalRef().
> > However, I'm not sure if ExceptionClear() won't dispose exception
>
> ExceptionClear zeroes a reference to exception object in TLS which is
> considered as no exception state. The object itself may be collected
> later if there are no live references to it left.
>
> > object itself. To my mind it's better to fix NewGlobalRef() and make
> > it compatible with RI.
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp17626
>
> --
> Gregory
>
>