harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Wed, 18 Oct 2006 08:52:03 GMT
Hello.

My answers is here:

a) About resolving during compilation time

If Jit compiles call of the method from the current class, it means that
resolving has been already done, and not additional resolving is not
required to understand is class implements magic interface or not. If Jit
compiles call of the method from other class it should resolve that class to
understand is it usual call or JNI, as I understand. So no additional work
again.



b) About call of java method during compilation time. Jit now make class
loading during compilation. It means that Jit make call of java method. So I
don't think that it's the other case. To provide work of getCallAddress
without class initializing, additional requirements can be put forward. If
Jit will implements lazy resolution in future, compilation of the method
call and getCallAddress invoking will be put into lazy resolution stub.



c) Use of special interface is right for security issues. It's not clear for
me how provide security in Mikhail scheme.

Thanks
Pavel Afremov.

On 10/18/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:

> 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
> 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
> 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 – 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
>
>

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