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
 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:references;
        b=mjVqJVT19b5AXs8vhPgioUpAGdRtZH4G80xv2trtekhGY66PRhw8bpHGZiYoiW/byqBKMUT3RnWrHqelN9x6LtUhcmyTRaSg2i5pur5xCmZNQfOGpyc1SH5LcG0Me0utewpQU/HB12xgBx55e97BjZum/5Gek+tMH5z/0DFpbhM=
Message-ID: <bc79dd600610172334u2ab84d92mcf79a79d1ef8fbf8@mail.gmail.com>
Date: Wed, 18 Oct 2006 13:34: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: <783bf8b0610171212n41d1f47cm37fd77670039c9ec@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_65952_169327.1161153251781"
References: <bc79dd600610170640n1e58468ay10e5a9f091b50d4f@mail.gmail.com>
	 <51d555c70610171014gd507b14hce9f2c80b6096c04@mail.gmail.com>
	 <783bf8b0610171212n41d1f47cm37fd77670039c9ec@mail.gmail.com>

------=_Part_65952_169327.1161153251781
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Pavel,
I completely agree with Alex critics. But the thread is to discuss and to
find the best solution that could be implemented fast.
Sorry, some questions I have are the same as Alex's.

On 10/18/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
> 1)       The special interface MagicNativeCall should be created. The
> interface has only one method CallAddress getCallAddress(String
> methodName).
> All native methods of classes which implement this interface should be
> called by JIT via special "magic" way.


a. Object instance? Where should I get it during the compilation?
b. Why to use marker interface if we can use annotations to provide all
knowledge we need in the same way (e.g. calling convention/if native/other
knowledge that may be needed)?

2)       If JIT find call of native method, it tries to find call address
> using getCallAddress method. If null is returned by the method, usual cal=
l
> of JNI method should be processed. In other case magic native call can be
> included instead JNI call. Result returned by getCallAddress can
> and  should
> be cashed by JIT for performance reasons.


a. Self-describing Java code (I mean getCallAddress()) - this is very good.
b. Calling virtual method from the JIT during the compilation is not a good
idea.


3)       I propose for the firs time use fastcall calling convention. In
> future new additional method can be added MagicNativeCall interface. It
> can
> be named as getCallType for example. If it returns JNI =96 jit should use
> stdcall, if FastWay =96 fast call. Also we can add special Magic type of
> calling convention. In this type of call one can select Register and stac=
k
> slot for every parameter and return value.


a. The development is limited to support only basic CCs - I agree. All othe=
r
calling convention could be discussed latter.
b. Why to use "abstract lists" but not the named and typed parameters like
in Java?

--=20
Mikhail Fursov

------=_Part_65952_169327.1161153251781--