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 mike.fursov@gmail.com
 designates 209.85.132.246 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:references;
        b=uYW2BA3sll0OIr918kSzoMSIxjZB7hi2r0Z9m/uNpzH6sWU7fn0XQNUzGJ/jdjBCeVMDZkefAjHEuV2uvLUNxvRZJ2l4RHi+hVbd6WF0j/rccoMb3YoDBX3Vz5ATqLtfpHlSER7Yu//aP7wF8SYcqLqu2oB43Ho9+naE2wXVz9M=
Message-ID: <bc79dd600701260711t70b73f40qd4fe2292cd9d6537@mail.gmail.com>
Date: Fri, 26 Jan 2007 21:11:05 +0600
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][magic] New Magic features proposal.
In-Reply-To: <783bf8b0701250237u2a83b847wbd3a6476b87d4147@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_10336_18779942.1169824265338"
References: <783bf8b0701220250n4cd3b553kd97a07e72a1ecfa6@mail.gmail.com>
	 <783bf8b0701220403n70faf048l560500712d274a3f@mail.gmail.com>
	 <59713.210.9.143.64.1169473196.squirrel@sqmail.anu.edu.au>
	 <bc79dd600701221007m1d537b7bs25b40d15e3dfb40e@mail.gmail.com>
	 <45478.152.91.9.201.1169517639.squirrel@sqmail.anu.edu.au>
	 <9623c9a50701230721i9237008mc370d0d941d71d4f@mail.gmail.com>
	 <bc79dd600701230730i235b892al6c75cb20064492c5@mail.gmail.com>
	 <9623c9a50701231916v6a9f3521taf2423587ed5b883@mail.gmail.com>
	 <bc79dd600701240759u46777c1fued0b9dafc99410c3@mail.gmail.com>
	 <783bf8b0701250237u2a83b847wbd3a6476b87d4147@mail.gmail.com>

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

On 1/25/07, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
>
> The other possible way use annotation instead  MyJNICalls
> andMyNativeFastCalls
> classes.


Yes, I vote to have annotations for JNI methods to describe how to call JNI
method. More specifically annotation must say which Java method to use as a
fast path helper for a JNI call.

For a method without annotation we can assume that the method has all
possible side-effects and use our default helper.
Here is the scenario with a solution how to pass arbitrary number of params
from magic JNI helper into the native method in Java.


Example 1.
//JNI call without special annotation -> use default helper
private static native void onTimeout();

The body of the default JNI helper:
void VMHelperFastPath::callNativeDefault(Address method_handle) {
    //prepare all VM stuff (allocate M2N on stack, fill all required
fields...)
    Address m2n = ..;
    Address jniEnv = ..;
    VMHelper::doDirectJNICallDefault(m2n,jniEnv);
    //proccess all sideeffects.
}


The most interesting part here is what VMHelper::callDirect is and where are
params and call result?
The answer is: JIT knows the semantic (but not internals!) of the helper: it
expects that JNI call will be replaced with direct call. To call JNI method
directly JIT must have several additional params like JNIEnv or m2n address.
All other params and return value stays the same as in original call and JIT
is able to restore them from helper inlining context.

Example 2. JNI call with special annotation: method has no side effects:
//@use JNI helper with name="VMHelperFastPath::callNativeFast" annotation is
here
   private static native int getTimeout();


void VMHelperFastPath::callNativeFast(Address method_handle) {
    //nothing to prepare
    Address jniEnv = ..;
    VMHelper::doDirectJNICallFast(jniEnv);
    //nothing to process here
}


So, finally we have 3 new feature to support in JIT
1) On-stack allocations
2) Direct JNI calls with M2N context prepared
3) A contract that magic JNI wrapper calls original JNI method - so JIT can
handle it's params and return type.


Are there any potential drawbacks that I missed here?


-- 
Mikhail Fursov

------=_Part_10336_18779942.1169824265338--