harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][magic] New Magic features proposal.
Date Fri, 26 Jan 2007 15:11:05 GMT
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
    Address m2n = ..;
    Address 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
   private static native int getTimeout();

void VMHelperFastPath::callNativeFast(Address method_handle) {
    //nothing to prepare
    Address 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message