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] Calling native methods from Java code: implementation details
Date Wed, 18 Oct 2006 06:34:11 GMT
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 call
> 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

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 – jit should use
> stdcall, if FastWay – fast call. Also we can add special Magic type of
> calling convention. In this type of call one can select Register and stack
> slot for every parameter and return value.

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

Mikhail Fursov

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