harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Thu, 19 Oct 2006 02:15:36 GMT

One more note.

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

It is different.
The JIT itself does not call Java code.
All what JIT does is calling VM's resolve_{anything}. It's VM who may 
execute the Java code during the resolution.

The JIT itself neither has a way to call an arbitrary Java method during 
the compilation, neither has an access to JNI functionality.


Pavel Afremov ?????:
> 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

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message