Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mike.fursov@gmail.com designates
 66.249.92.171 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:references;
        b=UR/cWDx4jLj2t0TNVt+VeJy71k94QUAgiAzBkihv7heY/1rUQLDKzLFuB4zlVWgIRRfyUqKNbG+tYfzGJbChkoKwVuCDTkxA+vCdGJcmRIGIBDKfjTR7Tn6Snh2l1sUinQDoanpe20bWI6RX5693gc2du3Lhql8z5NQr1rLO5fI=
Message-ID: <bc79dd600610172347k5018f878pb417573a6e4a58a3@mail.gmail.com>
Date: Wed, 18 Oct 2006 13:47:11 +0700
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Calling native methods from Java code: implementation
 details
In-Reply-To: <9623c9a50610171736x39ee6619o68558e4fd39c4564@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_66004_1233585.1161154031450"
References: <bc79dd600610170640n1e58468ay10e5a9f091b50d4f@mail.gmail.com>
	 <51d555c70610171014gd507b14hce9f2c80b6096c04@mail.gmail.com>
	 <783bf8b0610171212n41d1f47cm37fd77670039c9ec@mail.gmail.com>
	 <9623c9a50610171736x39ee6619o68558e4fd39c4564@mail.gmail.com>

------=_Part_66004_1233585.1161154031450
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/18/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> Pavel's looks like more flexible, but I have a question with the
> special interface approach: is it possible that sometimes we want to
> call a library native method in fast way? If possible, shall we
> require all library classes that have the native method implement the
> special interface?


The solution if my proposal is accepted: to call any native method from a
native library user must
1) Create a "header"-like Java file with a static method stub and describe
its parameters
2) Add the "Java header" to the protected by VM classes (e.g. load it with
bootstrap classloader)
3) Create a library that will be loaded by component manager and will
resolve the method by (void* getAddress(name)) request.
I think this is reasonable amount of actions to add unsafe functionality
into VM.


Or, is it possible for the VM developer to override a library native
> method with a fast internal replacement that still keeps the
> semantics? In this situation, this method is not really implemented in
> the library class. Where will JIT find it?


In my proposal: Yes.  A component (VM,GC) can return an address not only
for  'persistent' functions but of  generated ones (like helpers we have
today)

And we probably don't want over-generality to the design of fast
> native method invocation. We'd better keep them internally to the VM
> at the moment until we see real need to open this contract interface
> to external library/application developers. So if you agree with this,
> the set of non-JNI native methods for JIT to handle are very limited
> -- they are actually just some JVM internal functions (plus some
> special cases for speedup). We probably want them more closed than
> open just like the inlined helpers.


Completely agree. This functionality must be invisible for usual Java
developers. Before we realize we need it we must hide the functionality from
classlib developers too.

-- 
Mikhail Fursov

------=_Part_66004_1233585.1161154031450--